Skip to main content

Full text of "Proceedings of the hypertext standardization workshop January 16-18, 1990 National Institute of Standards and Technology"

See other formats


NIST Special Publication 500-178 



A111Q3 3fiTSbfl . 

v^uiripuc^r 

Systems 
Technology 

U.S. DEPARTMENT OF 
COMMERCE 
National Institute of 
Standards and 
Technology 

Nisr 

NIST * 
PUBLICATIONS 



Proceedings of the Hypertext 
Standardization Workshop 
January 16-18, 1990 
National Institute of Standards 
and Technology 



Judi Moline 
Dan Benigni 
Jean Baronas 



NATIONAL INSTrrUTE OF STANDARDS & 
TECHNOLOGY 
Reseso'di Mormatkm Center 
Gakhersburg, MD 20899 



DATE DUE 






. _ 






















































r ■ 











































































Demco, Inc. 38-.293 



NIST Special Publication 500-178 



Proceedings of the Hypertext 
Standardization Workshop 
January 16-18, 1990 
National Institute of Standards 
and Technology 



Judi Moline, Dan Benigni, and Jean Baronas, Editors 

Hypertext Competence Project 
National Computer Systems Laboratory 
National Institute of Standards and Technology 
Gaithersburg, MD 20899 

March 1990 



U.S. DEPARTMENT OF COMMERCE 
Robert A. Mosbacher, Secretary 

NATIONAL INSTITUTE OF STANDARDS 
AND TECHNOLOGY 
John W. Lyons, Director 




Reports on Computer Systems Technology 



The National Institute of Standards and Technology (NiST) (formerly the National Bureau of Standards) 
has a unique responsibility for computer systems technology within the Federal government. NIST's 
National Computer Systems Laboratory (NCSL) develops standards and guidelines, provides technical 
assistance, and conducts research for computers and related telecommunications systems to achieve 
more effective utilization of Federal information technology resources. NCSL's responsibilities include 
development of technical, management, physical, and administrative standards and guidelines for the 
cost-effective security and privacy of sensitive unclassified information processed in Federal computers. 
NCSL assists agencies in developing security plans and in improving computer security awareness train- 
ing. This Special Publication 500 series reports NCSL research and guidelines to Federal agencies as well 
as to organizations in industry, government, and academia. 



National Institute of Standards and Technology Special Publication 500-178 
Natl. Inst. Stand. Technol. Spec. Publ. 500-178, 259 pages (Mar. 1990) 

CODEN: NSPUE2 



U.S. GOVERNMENT PRINTING OFFICE 
WASHINGTON: 1990 



For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402 



PREFACE 



This report constitutes the proceedings of a three day workshop on Hypertext 
Standardization held at the National Institute of Standards and Technology (NIST) on 
January 16 - 18, 1990. The workshop was the first in what we hope becomes a series of 
standardization efforts. The workshop was sponsored by the Hypertext Competence 
Project of the National Computer Systems Laboratory of NIST. 

The workshop included plenary sessions and three disscussion groups. Because the 
participants in the workshop drew on their personal experiences, they sometimes cited 
specific vendors and commercial products. The inclusion or omission of a particular 
company or product does not imply either endorsement or criticism by NIST. 

We of the Hypertext Competence Project gratefully acknowledge the assistance of all 
those who made the workshop a success. Further, I want to thank Dave Stotts for 
designing the cover graphic. 

Judi Moline 
January 29, 1990 



PROGRAM COMMITTEE 

Len Gallagher, Chairman 

Jean Baronas 

Dan Benigni 

Richard Fumta 

Judi Moline 

David Stotts 



- iii - 



CONTENTS 



ABSTRACT 1 

INTRODUCTION 3 

REPORTS OF DISCUSSION GROUPS 5 

1. HYPERTEXT MODELS DISCUSSION GROUP 7 

1.1 Reference and Data Model Group: Work Plan Status 9 

1.2 Reference and Data Model Group: Comparison of Three 

Models 15 

1.3 Reference and Data Model Group: Responses to 17 

2. DATA INTERCHANGE DISCUSSION GROUP 19 

2.1 Summar>' of the Hypertext Interchange Group 21 

2.2 Note on Representing Anchors 23 

3. USER REQUIREMENTS DISCUSSION GROUP 27 

3.1 Report from the User Requirements Working Group 29 

PAPERS 37 

1. Bomstein, J. & Riley, V. - Hypertext Interchange Format 39 

2. Brown, P.J. — Standards for Hypertext Source Files: the Experience of UNIX 
Guide 49 

3. Cole, F. & Brown, H. Standards: What Can Hypertext Learn from Paper 
Documents? 59 

4. Crane, Gregory -- Standards for a H3/permedia Database: Diachronic vs. 
Synclironic Concerns 71 

5. Furuta,R. & Stotts,P.D. -The Trellis Hypertext Reference Model .... 83 

6. Halasz, F. & Schwartz M. - The Dexter Hypertext Reference 

Model 95 

7. Hardt-Komzacki, S. et al. - Standardization of Hypermedia: What's the 

Point? 135 

8. Lange, Danny B. - A Formal Model of Hypertext 145 

9. Marshall, Catherine C. - A Multi-Tiered Approach to Hypertext Integration: 
Negotiating Standards for a Heterogeneous Application 

Environment 167 

10. Newcomb, Steven R. - Explanatory Cover Material for Section 7.2 of 

X3V1.8M/SD-7 179 



- V- 



1 1 . Oren, Tim - Toward Open Hypertext: Requirements for Distributed 
Hypermedia Standards 189 

12. Parunak, H. Van Dyke - Toward a Reference Model for 

Hypermedia 197 

13. Riley, Victor A. - An Interchange Format for Hypertext Systems: the 

Intennedia Model 213 

14. Thompson, Craig W. - Strawman Reference Model for Hypermedia 

Systems 223 

APPENDICES 247 

1. Kahn, Paul -Hypermedia Bibliography, 1989 249 

2. Participants 265 



- vi 



ABSTRACT 



This report constitutes the proceedings of a three day workshop on Hypertext 
Standardization held at the National Institute of Standards and Technology (NIST) on 
January 16 - 18, 1990. Efforts towards standardization of hypertext have already been 
initiated in various interested organizations. In recognition of these existing efforts, NIST 
sponsored the Hypertext Standardization Workshop organized by the Hypertext 
Competence Project of the National Computer Systems Laboratory. 

The major purpose of the Hypertext Standardization Workshop was to provide a 
forum for presentation and discussion of existing and proposed approaches to hypertext 
standardization. The stated workshop goals were to consider hypertext system definitions, 
to identify viable approaches for pursuing standards, to seek commonality among 
alternatives whenever possible, and to make progress towards a coordinated plan for 
standards development, i.e. a hypertext reference model. The workshop announcement 
solicitated contributed papers on any aspect of hypertext standardization, including 
assertions that standardization is premature or inadvisable. Approximately 30 
contributions were received and distributed to the 65 workshop participants on the first 
day. 

The workshop included plenary sessions and three discussion groups. This 
proceedings includes the papers selected for presentation in plenary sessions, reports of 
the discussion groups, and supplementary materials. Major conclusions of the workshop 
were that the discussion groups should continue their technical efforts, and that NIST 
should sponsor at least one more workshop to provide a forum for public discussion of 
progress. 

Key words: hypermedia; hypertext; standards. 



-1- 



INTRODUCTION 



Over the past several years we have seen a significant increase in the availability of 
document and information management systems that call themselves Hypertext or 
Hypermedia implementations. These systems have received a degree of acceptance from 
the user community and are being integrated into an increasing number of application 
development projects. There is every reason to believe that this trend will continue to 
grow and influence the marketplace in the foreseeable future. 

Although, at present, Hypertext/Hypennedia systems have no agreed formal 
definition, there is agreement on some of the underlying concepts that characterize them. 
Recently, a number of authors have stated requirements for hypertext standards and some 
have offered definitions and initial specifications for consideration. In several cases, 
specialized standardization efforts have already been initiated through interested 
organizations. In recognition of this emerging activity, the National Institute of Standards 
and Technology (NIST) sponsored the Hypertext Standardization Workshop. One 
consideration of the workshop was to determine if the evolution of Hypertext and 
Hypermedia technologies has reached the point where it makes sense to consider formal 
standardization. 

The major purpose of the Hypertext Standardization Workshop was to provide a 
forum for presentation and discussion of existing and proposed approaches to hypertext 
standardization. We solicitated contributed papers on any aspect of hypertext 
standardization, including assertions that standardization is premature or inadvisable. We 
received approximately 30 contributions totaling more than 400 pages, which were 
distributed to all workshop participants on the first day. The stated workshop goals were 
to consider hypertext system definitions, to identify viable approaches for pursuing 
standards, to seek commonality among alternatives whenever possible, and to make 
progress towards a coordinated plan for standards development, i.e., a hypertext reference 
model. 

Of the contributed papers, those of particularly high quality and general interest were 
accepted for publication and featured during a plenary session on the opening day of the 
workshop. Each author was given approximately 25 minutes to present a particular point 
of view. These individual papers are presented alphabetically in this proceedings. The 
remainder of the first day and all of the second day consisted of discussion groups set up 
in response to issues raised in the contributed papers. 

Three discussion groups met in parallel on the topics of Hypertext Models, Hypertext 
Data Interchange, and Hypertext User Requirements. Each group chose one or more 
"Presentors" to convey group opinions to the whole workshop. Summaries of the 
deliberations and conclusions of these discussion groups, authored by the presentors, are 
included herein. 



The morning of the third day of the workshop consisted of reports from each of the 
three discussion groups and a general discussion of where to go from here. In general, the 
groups were quite pleased with their progress and expressed a desire to meet on a 
somewhat regular basis to continue deliberations. There was general agreement that a 
recognized hypertext/hypermedia standards group could function as the focal point in 
defining a hypertext data model and a reference model that addresses other more 
specialized activities in areas such as documents, graphics, video, and sound. 

Craig Thompson raised the issue of establishing a more formal hypertext/hypermedia 
"study group" with regular scheduled meetings and operating procedures. Possibilities for 
organizing such a group under the auspices of ACM, X3, IEEE, GCA, MIST, or some 
other ANSI accredited organization were discussed, but with no definitive conclusion. 
Interested individuals were encouraged to pursue possibilities within these organizations. 

Major conclusions of the workshop were that the individual discussion groups should 
continue their respective technical efforts, possibly via private communications, and that 
NIST should sponsor at least one more workshop to provide a fomm for public discussion 
of progress. A decision could then be made as to the desirability of establishing a more 
formal standardization group with status in some ANSI accredited standards organization. 

Leonard Gallagher 
Workshop Chairperson 



-4- 



REPORTS OF DISCUSSION GROUPS 



This section of the proceedings contains the reports as submitted by the presenters of the 
discussion groups. The material was presented at the closing plenary of the workshop. 



-5- 



1. HYPERTEXT MODELS DISCUSSION GROUP 



Moderator: 


Judi Moline 


Presentors' 


Van Pariinak 




John Le?eett 




Jim Black 


Scribe: 


Robert Miglin 




JiJliii L/C^gjCLL 




W/i 111 T r^fti 1 c 
VV llllalii IvUilUo 


James Black 


Robert Miglin 


John C. Chen 


Judi Moline 


Qi Fan Chen 


Howard Moncarz 


Paul Clapis 


Taeha Park 


Fred Cole 


Van Parunak 


Andrew Dove 


John Puttress 


Robert Edmiston 


Louis Roberts 


Lawrence Fitzpatrick 


Linda Rosenberg 


Richard Furuta 


Andrea Spinelli 


Frank Halasz 


David Stotts 


Shoshana Hardt-Komacki Craig Thompson 


Kris Houlahan 


Magda Wright 


Danny Lange 





Reports of this group follow: 

• Reference and Data Model Group: Work Plan Status 

• Reference and Data Model Group: Comparison of Three Models 

• Reference and Data Model Group: Responses to "Issues for Discussion Group 
Consideration" 



-7- 



Reference and Data Model Group (RDMG): 
Work Plan Status 



Reported by 
H. Van Dyke Parunak 
Industrial Technology Institute 

January 26, 1990 



Abstract 

A reference model is a structured description of some domain that can be used to compare existing imple- 
mentations in that domain, design new implementations, and (most important for our purposes) map out 
possible areas for standardization and show their relation to one another. The main output of the RDMG 
during the NIST workshop was a work plan for arriving at such a reference model. The wwk plan that 
we propose has the following structure, where the flow of activity is down the page (except for the single 
feedback loop), and where activities marked by '*' received significant attention during the workshop. 

+ + + + 

I I II 

V V V I 

♦Define *Brainstorm *Coinpare Existing I 

"Hypertext" Concepts Models (DTL) I 

\ I / I 

\ V / 1 

♦Organize Ontology I 

1 I 

V I 
Rank Concepts by Centrality I 

I I 

V I 
Inventory Existing Systems I 

I I 

V I 
Construct "Implementation" Model I 

I I 
+ + 

V 

Select Areas for Standards 

The rest of this document defines each of these steps, and reports what we have done in each of them. 

This document summarizes the portion of the final RDMG presentation that I delivered on 18 January 
1990. It represents my perception of the deliberations of the group, but has not been reviewed or formally 
approved by the other members. 



1 Define 'Hypertext' 



This definition is intended to be a brief, succinct statement of our domain, to provide some degree of focus 
during subsequent stages. It may well change considerably as a result of later analysis. We began with 
a definition that has been circulating for several years, and modified it to reflect the valuable distinction 
between 'hypertext' (as a structured body of information) and 'hypertext system': 

A Hypertext is a network of information nodes connected by means of relational links. 

A Hypertext System is a configuration of hardware and software that presents a Hypertext to users and 
allows them to manage and access the information that it contains. 

2 Brainstorm Concepts 

In an effort to scope our discussions, we brainstormed terms and concepts describing hypermedia, and 
assembled a list of about 80. These are listed in more organized fashion below. 

3 Compare Existing Models 

In order to build on existing work, representatives of three detailed models presented at the workshop (the 
Dexter model, the Trellis r- model, and Danny Lange's model) compared and contrasted their respective 
models. A separate report by John Leggett summarizes those discussions. 

4 Organize Ontology 

We attempted to organize the set of terms and concepts to bring like things together. This section reviews 
the resulting taxonomy of concepts, and then describes some further analysis that might be conducted to 
organize the list even further. By itself, this organized list is a limited reference model. Subsequent steps 
refine it and seek to cast it in a form that has been useful in the past in guiding the development of standards. 

4.1 A Preliminary Organization 

We found it useful to sort the concepts produced by brainstorming into three main categories: Entities, 
Properties, and Functions or Operations. Some concepts did not seem to fit cleanly into any of these, and 
were relegated to a catch-all category, Abstractions. 

Entities These are the objects that a hypertext system must manipulate; together, they make up a hy- 
pertext. 

• Components, each with a UID (unique ID) 

— Link or relationship; may be warm, hot, abstract, dynamic. 

~ Nodes; can have fields, contents, anchors/buttons/interactors/Iink markers 

— Composites, including idioms, paths, tours, webs, networks 

• Whole documents, also with UID's (container, stack, frame set, guideline) 

• Navigational aids, including index, map, table of contents, fisheye view 

• Display entities: window, canvas. Card vs. scroll distinction applies here. 

• Functional stuff: presentation specification; resolver. 



-10- 



Properties These can be either of entities or of the entire system. 

• Properties of Entities (should probably be merged with the Entity term list) 

— Attributes (of nodes and links; includes temporal and display behavior) 

— Component format and structure (e.g., locktext) 

— Network topology (e.g., hierarchy, hypercube, DAG) 

— Size of canvas (scroll vs. card) 

• Properties of the System 

— Concurrency, including both multiuser and multithread 

— Synchrony 

— Existence of a formal model 

— System performance (e.g., speed) 

— Timing (e.g., to support music, animation, and video) 

— Distributed vs. local 

— Monolithic vs. open (as in a link service or link protocol) 

— Referential integrity (are dangling links permitted?) 

— Context sensitivity 

— Interoperability 

— Operating modes (browse, author, ...) 

Functions Initial attempts to classify these further were unsuccessful. We finally did a hierarchical clus- 
tering, joining the closest two items into one, and repeating until we had a reasonable number of classes. 
This process yielded the following taxonomy, to which we have added names that seem to summarize the 
contents of each group: 

• Knowledge modification 

— Modifying system knowledge in place: edit (including cut/paste and structured editing), update, 
annotate 

— Move information into or between systems: interchange; conversion and parsing of raw text 

• Navigation 

— Search and query; need for managing relevance of search; filters 

— Browsing semantics (progressive disclosure; histories; views; path macros; bookmarks) 

— Support tools: scripting, addressability, triggering (actions to take on arriving and departing a 
node) 

• 'Yucky Systems Stuff' 

— Tailoring 

— Interfaces, of two sorts: 

* Foreign nodes (application programs that can be activated at a node); API's 

* Communications protocols (between separate programs at the same layer) and services (be- 
tween layers of a single program) 

— Versioning, journaling 

— Access control 



-11- 



Abstractions This is a catch-all category for a number of terms that didn't seem to fit elsewhere. Alter- 
native titles for this group of terms are 'metadata' and 'implementation tools.' 

• Schema 

• Type 

• Class 

• Object 

• Data models (E-R, semantic) 

• Encapsulation 

• Layer 

4.2 Further Organization 

One can go further (though we didn't have time). For example: 

• Developing a 'Properties x Functions' relation to show what functions are needed to support what 
(systems) properties. 

• Developing an 'Entities x Functions' relation to show what entities support what functions. 

5 Rank Concepts by Centrality 

In choosing areas for standardization, we want to focus on those topics that are characteristic of most or all 
hypermedia systems, and not on those that appear only in a few systems for special purposes. The intent 
here is to rank each topic as {-|-,0,— } to indicate how typical or critical it is for a model of mainstream 
hypermedia. 

6 Inventory Existing Systems 

One important use of a reference model is as a guide to comparing systems, and a test of the model that 
this process produces will be how useful it is for such comparisons. We propose the development of a matrix 
showing how various existing systems reflect the categories that we have developed, as a way of testing the 
completeness and consistency of our ontology. Discussion in the plenary session on this point highlighted 
the different results that would likely be obtained depending on whether one focused on commercial systems 
or on research systems. 

7 Construct 'Implementation' Model 

The objective here is to derive a layered model, like the OSI reference model, in which the layers represent 
successive functionality added to a core with hardware at the bottom. 

The group expressed some difference of opinion on whether OSI is a good example of what we want. 

An interesting discussion within the group centered on whether a monotonic layering from hardware to 
application was possible. One suggestion was that in fact there might be several implementation stacks, 
doing different tasks, for instance: 



-12- 







S T A 


C K S 




TASK: 


Store 


1 Process 


1 Present 


User 


LAYERS : 


Node .Link 
OODB 

File System 


1 Navigate 


1 Window, Button 

1 Virtual 
1 Terminal 


Concept 


DEVICE: 


Disk 


1 CPU 


1 CRT/Keyboard 


1 Eye/ 
Hand 



\ / \ / \ / 

MEDIUM: Bus LAN EM Radiation 



The layers listed in this diagram are incomplete, but illustrate the difference between those that are 
central to hypermedia and must be described in our model (above the dashed line), and those that should 
be developed in other disciplines (below the line). What is critical for our purposes is the clear definition of 
the services that connect one layer to another. 



8 Select Areas for Standards 

Once developed, a reference model helps map out areas for standards. Focus is important here, and the 
model helps provide it in two dimensions. The ranking of concepts in the ontology shows how central each is 
to hypermedia, and helps us focus on standardizing those concepts most likely to be of widespread use. The 
implementation model helps us identify which concepts are best standardized in other research communities 
(such as CHI, DB, OOPS, windowing systems) and which require the focused attention of researchers in 
hypertext. Graphically, the focussing process seeks to identify the region 'X' in the diagram below for 
standardization. 



CHI I I 

+ _V 

Which HT I X <— 

Community? +_--_-------------- 

DB. i 1 
OOPS I I 

+ • 

All HT few 
Systems Systems 
How central is it to hypertext? 



-13- 



Reference and Data Model Group: 
Comparison of Three Models 

John J. Leggett 
Department of Computer Science 
Texas A&M University 

The Reference and Data Model working group spent 45 minutes comparing and contrasting the R-model-^, 
Dexter"' and Lange^ reference models. David Stotts, Danny Lange and John Leggett spent another 90 
minutes over dinner discussing the three models. A summary was provided by John Leggett during the final 
plenary session. As these three models are currently under development, the comparisons are rather broad 
in nature. It is interesting to note that the three models were developed independently and with varying 
levels of collaboration. The results of these discussions are presented below in mostly tabular form. 



Differences 

Type Links Anchors Formalized? 

R-model Meta-model for No links, but No distinct No 

systems specification relations defined anchors 

Lange Model of hypertext Allows dangling Anchors and Yes, in VDM 

links regions 

Dexter Model of hypertext Does not allow Anchors Yes, in Z 

systems dangling links 



Similarities 

Support for types in all three models is through arbitrary attribute/ value pairs. 
All three models have separated content, structure and presentation: 

Content Structure Presentation 



R-model Abstract content Structure and Concrete and 

abstract containers visible levels 

Lange Schema Networks and Unspecified 

structures 

Dexter Within-component Storage layer Run-tim.e la3'er with 

layer presentation specifications 



^Ridiard Furuta and P. David Stotts, "The Trellis Hypertext Reference Model," these proceedings. 
^ Frank Halasz and Mayer Sdiwartz, "The Dexter Hypertext Reference Model," these proceedings. 
^Danny B. Lange, "A Formai Model of Hypertext," these proceedings. 



-15- 



H>'pertext Reference Model Group 
Responses to "Issues for Discussion Group Consideration" 

James Black 

1. What is the current state -of-aff airs in this topic area? What is likely to happen in the 
near future? 

The Reference Model Working Group did a reasonably thorough examination of three 
independently derived hypertext models and identified no essential inconsistencies which 
would preclude eventual consensus. Each of the three models was the product of a 
different analytical approach and there remain significant areas of confusion and lack of 
current consensus which seem to largely due to syntactical differences. Further open 
dialogue among the participants would improve this situation. 

2. Are emerging technologies driving this topic in a certain direction? Is there sufficient 
stability to warrant further pursuit of standardization at this time? 

The sessions revealed no clear evidence that "emerging technology" was driving any 
aspect of the hypertext concept in a particular direction. The only indication of any 
"driving forces" which may be prematurely affecting aspects of the evolution of hypertext 
technology are related to other standardization efforts, specifically, ODA and 5G(a . There 
does seem to be sufficient stability in the shared understanding of basic hypertext 
concepts to warrant further pursuit of standardization. 

3. What are the most important concepts? Ale there agreed definitions? Is there a glossary 
available, or set of candidate key words? 

The essential concepts of hypertext would include a data model with the following 
features: 

• data type and media independence 

• "fonnat" and "content" independence 

• freely defined, relational links between freely defined data elements 

• no inherently hierarchical structure 

• distinct separation of format and content 

They would also include such functional features as navigational, authoring, presentation, 
and systems management tools. 

4. What is the interdependency of this topic area with other topic areas identified at this 
workshop? 



-17- 



There is a need to develop a glossary and taxonomy of hypertext terminology which 
includes formal, (mathematical) definitions where available. There is available a core set 
of candidate key words. 

5. What are the major problems and controversies? Is compromise possible? or would 
alternative approaches better serve the vendor/user communities? 

There is significant interdependency between the hypertext reference model and 
system interchange issues. 

6. What is the ultimate goal for this topic area? a user guideline? a domestic standard? an 
intemational standard? something else? What is an appropriate sequence of steps leading 
to this goal? 

The ultimate goal of this working group is to establish a hypertext system reference 
model and use it to establish a hypenext glossary and taxonomy and to identify candidate 
areas for standardization activity. 

7. What concepts in this area are appropriate for standardization? What concepts are not 
appropriate for standards? What can inhibit the development of standards? Is something 
ready for standardization at this time? 

There are no areas ready for standardization at this lime. 

8. What role can NIST play in achieving the goals of this topic? Aiq further workshops 
desirable? What is the most appropriate follow -on activity after this workshop? 

NIST can establish a formal, on-going hypertext study group that publishes consensus 
findings and recommendations which NIST links to relevant standards organizations. 



-18- 



2. DATA INTERCHANGE DISCUSSION GROUP 



Moderator: Len Gallagher 
Presentor: Tim Oren 
Scribe: Jan Walker 



Rob Akscyn 
Gregory Crfine 
Valerie Florance 
Edward A. Fox 
David Fristrom 
Len Gallagher 
Steve Newcomb 
Charles Nicholas 
Tim Oren 
Kenneth Pugh 
Victor Riley 
Jan Walker 



Reports of this group follow: 

• Summary of the Hypertext Interchange Group 

• Note on Representing Anchors 



-19- 



Summary' of the Hypertext Interchange Group 



The Interchange Group first discussed how the problem could be partitioned. We agreed 
that ideally the representation of the data and its presentation to the user should be 
separated. However, for efficiency reasons most existing hypertext systems which support 
graphics in fact store bit maps and specific screen coordinates. This is an obstacle to 
interchange between platforms with differing display architectures. 

We also made the distinction between a "delivery interchange" standard and an 
"archival interchange" standard. A delivery interchange standard would be directly 
usable by a conforming hypertext system without translation. We regarded this as very 
difficult to achieve in the short term due to differences in hypertext systems' methods of 
storing and indexing their data, which are usually highly optimized for the particular 
platform and application. The dependence on display formats already noted is also an 
obstacle to a delivery interchange standard. 

An "archival interchange" standard is one in which the information owner may store 
hypertext in a system independent fashion. For actual delivery either the information 
owner or end user would need to translate the archival interchange format into a format 
specific to a particular hypertext software/hardware configuration. Any changes authored 
by the end user would have to be rolled back to the archival store before reaching other 
platforms, rather than attempting direct interchange. We agreed that this goal was more 
achievable in the shoit run, and turned our discussion in this direction, but without 
disputing the eventual value of a delivery interchange format, or the need for further 
experiments with delivery to define requirements for the archival representation. 

We proceeded to compare relevant interchange proposals from the working papers or 
which were otherwise drawn to the attention of the group. These included a discussion 
paper submitted by Ken Pugh, Victor Riley's Intermedia exchange paper, portions of the 
HyTime proposal, and the so-called "HIP" Hypertext Interchange Protocol developed at 
Apple, Xerox PARC and Brown IRIS. A copy of the HIP paper was supplied by Victor 
Riley of Brown IRJS. The group voted to request that the HIP paper (Bomstein and ROey. 
"Hypenext Interchange Format") and relevant sections of HyTime (Newcomb, 
"E.xplanatory Cover..." and Section 7.2) be included in the final Proceedings of the NIST 
Workshop. 

Comparing these formats showed that all were adopting a partitioning of the problem 
into data objects, anchors, and links. Anchors form the data object type specific endpoints 
for links. While there were abundant differences in terminology, a first reading showed 
basic conformance to this layering, and we agreed that this should be drawn to the 
attention of the modeling group. 

It was also noted that most of the interchange proposals used SGML or SGML-like 
markups. After some discussion, it was agreed that SGML was a reasonable basis for 



-21- 



further interchange experiments. This position is adopted without prejudice to an 
eventual standard, due to a number of panicipants' concems about technical issues (e.g., 
efficiency, limits of a parser driven implementation), and prejudgment of the decision 
process. We agreed that documents resulting from these discussions should be conveyed 
to the HyTime (ANSI X3V1.M8) committee for inclusion in their working document set. 

A general discussion of related standards ensued. There was consensus that wherever 
possible hypertext interchange standards should incorporate existing media type standards 
without requiring changes in those standards. 

An ad hoc group composed of Ed Fox, Steve Newcomb, Tim Oren, and Victor Riley 
met during the evening to continue the comparison of the various interchange proposals. 
They reported to the whole group that they had succeeded in a first pass reconciliation of 
the anchor levels of HIP, Intermedia and HyTime. Their notes are appended in the 
interchange section of the proceedings (under the title "Note on Representing Anchors") 
rather than incorporated here, as they were not a result of the entire group. 

The whole group strongly suggests that further experiments with interchange between 
existing systems be undertaken. We noted the need for a publicly available, editorially 
controlled document set for this purpose. This should be in the few hundred to few 
thousand node size, marked up in SGML with linking information provided. Further 
volunteers and funding for these experiments are an issue. Availability of a free or 
inexpensive SGML parser is required if universities are to participate in the experiments. 

We identified a number of significant issues which were not addressed due to time 
constraints: 

• Making a complete list of relevant data type standards 

• Requirement for unique nammg and identification services, which is a problem with 
wider scope than hypertext alone. 

• Link typing, type definition and hierarchies, N-way link structures 

• Composites - a taxonomy of existing uses and representations 

• Versioning 

• Representation of time-based media, e.g., music, video, and links conveying timing 
information 

These should be addressed in further sessions, as they all influence requirements for an 
interchange standard and some (particularly link tj^mg and composites) are the subject of 
active research and controversy. 

Submitted by Tim. Oren 
January 24, 1990 



-22- 



Note on Representing Anchors 
Reported by Tim Oren 



An ad hoc subgroup of the Interchange working group met to compare various proposals 
for archival interchange. It was composed of Ed Fox, Steve Newcomb, Tim Oren, and 
Victor Riley. These notes are the result of that meeting. They are a first pass which has 
not been considered by any other group. See the summary of the Interchange group for 
context and definition of terms. 

We chose to proceed by focusing on the anchor or "anchor-like" portion of each 
proposal. We began by considering how the features of the Intermedia Interchange could 
be added to the HIP proposal, and expressed the result in HIP-like terms. We then 
attempted to reconcile this result with the formalism and language of the pertinent 
sections of HyTime. Note that this applies only to anchors, and there may be additional 
difficulties in reconciling layering strategies when we look at the link layers of the various 
proposals. 

1 . Reconciliation of Intermedia exchange and HIP 

This is a semi-formal presentation of patches to the <ANCHOR> section of the HIP 
specification. The other sections of HIP have not yet been brought into conformance: 

<NAME> - optional, ASCII string, user displayed or for use of system. Usage ideas: this 
could be the name of a hypercard button, or used as a item for searching, or as comments 
to be displayed as preview. 

<ID> - required, a unique ID in a format TBD. Uniquely identifies this anchor within the 
scope of the interchange set. 

<CREATION> - optional. 

<WHEN> - Date/time of creation in a standard form TBD. Indicates the moment 
of original creation of the anchor (even if it was later moved). 

<BY> - the unique ID (TBD) of the user/authority who created the anchor. 

<MODIFIED>* - optional, optionally multiple. 

<WHEN> - Date/time of the pailicuiar modify. It is a application policy maner 
whether all, just the latest, or no mods are recorded. 



-23- 



<BY> - the unique id of the modifying user/authority. 

<VERSION> - a unique id of the referenced version. How to use this is a policy 
matter of the system. If it's the same as the <ID> of this anchor, this is the current 
version. 

<LOCATION> - required. 

<ANCHOR-OBJECT-ID> - required. The unique ID of the data object (file - 
chunk - whatever) to which this anchor refers. 

< ANCHOR- VALUE>+ - object type specific, required, optionally multiple. Note 
that this could refer to multiple selections, elements, etc. within the data object. 

<PRESENT-SPEC> - object type specific, optional, regulates how the anchor is to 
be presented, e.g., run the sound editor or play the sound, positioning information 
for the 3-D editor view of an IGES object. 

2. Reconciliation with HyTime terminology (sections under 7.2.5) 

HyTime as written contains within its "location" layer information which is both generic 
to the concept of anchor, and specific to certain data types. We try to separate this here. 
Again, this has not been reconciled with the link layer of HyTime or HIP and problems 
might emerge there. 

The general concept of "endoc" corresponds to the HIP <ANCHOR> idea. The ID within 
entloc corresponds directly to the <ID> in HIP. The "dataent" corresponds to the 
<ANCHOR-OBJECT-ID> of HIP. 

Notation Data Location (ndloc) is HyTime 's generic anchor, corresponding directly to the 
HIP construct above. Its type specific part is represented in the "formula," which 
corresponds to the <ANCHOR-VALUE> of HIP. "Snap" should probably be considered 
part of a type-specific constmct rather than part of a generic anchor. HIP would probably 
represent it as part of the <PRESENT-SPEC>. A reasonable default data type is 
undifferentiated byte stream. 

The other location constructs are viewed as data type specific anchors. 

Character data set location (cdloc) is an anchor into sequences of ISO defined characters 
(NB: this is not the same thing as a font or byte sequence). 

Document locations (elemloc) (7.2.5.2-3) are the SGML object type specific anchor 
definitions. Element location is SGML type specific and identifies a single "node" within 



-24- 



the hierarchical structure created by an SGML markup. This may be specified using an 
ID, if one exists for the node, or using a path designator from the root. Point location 
allows anchoring to a spot within an element. 

All of these constructs might be further generalized by allowing multiple "selections" to 
be incorporated within one "location." 



-25- 



3. USER REQUIREMENTS DISCUSSION GROUP 



Moderator: Jean Baronas 
Presentor: Robert Glushko 
Scribe: Seymour Hanfling 



Carol Adams 
Peter Aiken 
Jean Baronas 
Denise Bedgord 
Tim Bemers-Lee 
Kevin Gamble 
Robert Glushko 
Louis Gomez 
Seymour Hanfling 
Casey Malcolm 
Catherine Marshall 
Fontaine Moore 
Dan Olson 
Duane Stone 
Clifford Un 
David Wojick 
Don Young 



Reports of this group follow: 
• Report from the User Requirements Working Group 



REPORT FROM THE USER REQUIREMENTS WORKING GROUP 



Robert J. Glushko 

Search Technology 
Norcross, GA 

This report summarizes meetings held on January 16-17, 1990 during a workshop on 
Hypermedia Standardization held at the National Institute of Standards and Technology in 
Gaithersburg, MD. In addition to the author, the members of the Working Group for User 
Requirements were Carol Adams, Peter Aiken, Jean Baronas, Denise Bedford, Tim Bemers-Lee, 
Valerie Florence, Kevin Gamble, Louis Gomez, Seymour Hanfling, Kathryn Malcolm, Cathy 
Marshall, Fontaine Moore, Dan Olson, Duane Stone, Clifford Uhr, David Wojick and Don 
Young. The group followed an agenda set by NIST to identify the current state of affairs, 
important driving and constraining factors, potential areas for standardization, and research 
needs. 

Complete consensus on these complex topics was impossible in two days for a group this 
size, so this report emphasizes the majority themes for the issues that received the most attention. 
I apologize for my own biases, which undoubtedly show through. 

THE CURRENT STATE OF AFFAIRS FOR HYPERTEXT 

In recent years hypertext concepts for making information more accessible and usable 
have been applied to a bewildering variety of applications: 

Reference books, encyclopedias, dictionaries 
Library collections and archival literature 
Online software reference manuals 
Policies, procedures, regulations 
Maintenance and diagnostic information 
Online help systems and embedded training 
Education, tutorials 
Engineering and CAD 
Professional project management 
Collaborative problem-solving and authoring 
Interactive fiction, entertainment 
Museum directories and information kiosks. 



-29- 



Four basic factors appear to account for the rapid spread of hypertext design concepts. 
These are enabling technology, documentation standards initiatives with hypertext implications, 
market pressure, and academic interest. 

Enabling technology. Hypertext applications require a significant amount of local 
processing power and storage capacity that until the mid 1980s was not readily available. 
Hypertext (and espec'ally hypermedia) applications are also benefiting from increased data 
transfer capabilities enabled by advances in data compression, fiber optics, and progress toward 
an end-to-end digital telecommunications network. Nevertheless, having the delivery and 
storage technology base for hypertext systems would have been meaningless without the 
concurrent maturation of user interface design concepts and tools. Object-oriented programming 
and prototyping toolkits that embody direct manipulation user interface concepts make it 
possible to design and implement the rich functionality of hypertext systems in a cost-effective 
way. 

Documentation standards initiatives with hypertext implications. Some major 
standards efforts in related areas have made hypertext both more necessary and more likely. The 
first of these is SGML, the Standard Generalized Markup Language [7]. In 1986 SGML became 
an international standard (ISO 8879) for defining the logical structure of printed documents 
independently of theii^ appearance. While there is no agreement that SGML is the optimal 
starting point for a hypertext standard, there is little dispute that SGML's system-independent 
markup makes it significantly easier to exchange and process electronic documents and hence, to 
combine them into hypertext documents. 

A second major standards initiative that is emerging as a driving force for hypertext is 
CALS, the U.S. Department of Defense program for Computer-Aided Acquisition and Logistic 
Support [3]. CALS has as its goal the creation of a "paperless environment" with the integration 
of the various "islands of automation" that participate in the system design, development, 
deployment, and maintenance processes. In February 1988 the CALS program adopted SGML 
as a military standard (MIL-M-28001) for the digital form of traditional printed documents, but 
new standards for creating, exchanging, and delivering information are evolving that completely 
do away with any notion of "printed page." Since so many companies do business either directly 
or indirectly with the Department of Defense, the scope of CALS will be enormous. The 
obvious benefits of digital information exchange throughout the entire government are causing 
CALS concepts and requirements to spill over into other parts of government. 

Market pressure. Programs that called attention to their hypertext features had started to 
emerge in the mid- 1980s, but since the release and aggressive marketing of HyperCard by Apple 
Computer in 1987, dozens of other software products that claim to provide hypertext and 
hypermedia capabilities have entered the marketplace since. 

Academic interest. Finally, substantial academic interest in hypertext issues has 
emerged in the last few years. In late 1987, approximately the same time as the introduction of 
HyperCard, a conference was held at the University of North Carolina that was the first 
academic rally of researchers and system designers under the hypertext flag [1], Since then, 
similar conferences have been held in Europe [9] and a second major conference on hypertext 



-30- 



was held in Pittsburgh in November 1989 
established with "hyper" in its name [6]. 



[2]. At least one new professional journal has been 



THE FUTURE 

The 1990s will see ubiquitous software and hardware support for hypermedia 
applications in "off the shelf computing environments. Computer hardware, software, and 
telecommunications companies will develop business strategies and product lines for multimedia 
systems, appUcations, and services. 

It is already readily apparent that no single hypertext design or hypertext software is 
appropriate for all applications or users. However, guidelines or standards for choosing design 
approaches or software tools are hard to apply without a framework for understanding the range 
of possible applications into which hypertext solutions might fit. 



NEW VIEWS OF THE HYPERTEXT " DESIGN SPACE" 

Nevertheless, the classification scheme for hypertext applications that this paper began 
with is too arbitrary to serve this important purpose. That scheme loosely categorizes hypertext 
applications according to the kind of information they contain, but has no rationale for defining 
the categories. Why aren't encyclopedias and dictionaries in their own categories? Shouldn't 
training and education be together? Clearly, a more abstract and robust scheme is needed for 
comparing, understanding, and generating hypertext applications. The working group discussed 
several alternative views of the "hypertext design space." 

Dimensional view 

An alternative that I have been developing is based on four non-orthogonal dimensions: 

User dimension: single users vs. groups vs. multiple unrelated users. Hypertext 
systems can be designed for single users, groups of users working collaboratively, or large 
communities of unrelated users. 

Information dimension: creation vs. conversion. Hypertexts can primarily contain new 
information created for the application or information obtained by converting information that 
already exists in conventional printed form. 

Task dimension: task-specific vs. general. Hypertext systems can be designed to 
support specific tasks or as general-purpose environments for building other hypertexts. 

Interface dimension: static vs. dynamic. Hypertexts can be primarily static archives for 
read-only browsing, can be relatively transient databases of periodically-published information 



-31- 



like news articles or product catalogs, or dynamic to support continuous collaborative authoring 
and commentary. 

To edit, or not to edit? 

An alternative framework for understanding the hypertext design space was proposed by 
Carol Adams. Her view is that all hypertext applications can be partitioned according to whether 
or not they allow users to edit the content of the basic hypertext units and the links between 
them. These two orthogonal dimensions yield four cells into which existing and potential 
hypertext applications might be categorized. 

The two clearest categories in this framework are applications in which both units and 
links can be edited, and "read-only" or pure "browsing" applications in which neither can. 
Applications of hypertext to software design or concurrent engineering domains might embody a 
fixed structure between unit templates and thus primarily support unit-only editing. Finally, 
applications that involve primarily link-only editing with permanent units might include archives 
or literary criticism. 



SPECIFICATION OF HYPERTEXT FUNCTIONS 

Standards for the appearance of hypertext user interfaces may not even be possible and 
are certainly premature. The range of applications that call themselves hypertext and the wide 
assortment of user interfaces they contain clearly argue that at best, subsets of standards or 
standards "families" would be appropriate. However, the working group concluded that users 
and application developers would benefit immediately from shared definitions and specifications 
for hypertext functions. "Functions" are defined here as operations carried out by a hypertext 
user interface on the entities managed by the hypertext storage layer [5]. 

The goals of specifications for hypertext functions are straightforward. They must: 

a) fit clearly into the hypertext reference model, 

b) be independent of presentation specifications, and 

c) unambiguously define the operational semantics. 

If these goals can be satisfied, perhaps standards for hypertext functions can emerge that 
can be organized into consistent subsets for different parts of the hypertext design space. Then, 
the interoperability of hypertext systems in the same region of the design space can be defined in 
terms of these functions. The working group began this ambitious effort by creating a list of 
functions and crudely separating them into "authoring" and "reader" subsets. No claim is made 
that these lists are complete. 

Authoring Functions 

1) Create (unit, Unk, composite) 



-32- 



2) Edit (unit, link, composite) 

3) Delete (unit, link, composite) 

4) Publish (unit, link, composite, hypertext). "Publish" means to give a hypertext 
component a degree of permanence in some current version or configuration of 
the storage layer. 

Reader Functions 

1) Indicate current unit 

2) Move to another unit 

a) defined spatially (e.g., arbitrary new location in display) 

b) defined syntactically (e.g., in order - "next," "back") 

c) defined lexically (e.g., unit name contains string "x") 

d) defined semantically (e.g., unit of type "x") 

e) defined temporally (e.g., previous current unit) 

3) Indicate presence of "expandable" structure 

4) Indicate whether currently expanded 

5) Expand current unit 

6) Close current unit 

Annotation Functions 

7) Create annotation 

8) Edit annotation 

9) Delete annotation 

Bookmark Functions 

10) Create bookmark 

a) implicitly when in unit 

b) explicitly by user action 

11) Delete bookmark 

12) Move to "book-marked unit" 

Functions on Virtual Structures 

13) Search (scope, specification) 

14) Define session (history, bookmarks, annotations) 



-33- 



15) Save session 

16) Restore session 

Miscellaneous Functions 

17) Print (Unit, link, linearization) 

Specifying Functional Semantics 

These lists of functions will be far more useful when accompanied by precise definitions 
of what they mean and the rules by which they can be combined. There are many notations for 
specifying the semantics of functions (e.g., [4]), but I will use an informal approach here that is 
commensurate with the rudimentary level of the working group's progress in developing the 
specifications. 

For example, BACK (NEXT (X)) = X defines the meaning of "NEXT" and "BACK" 
functions in a hypertext system as follows: if a reader navigates from a unit X using a "NEXT" 
function, the "BACK" function returns to the starting unit X. 

Similarly, DELETE (CREATE (X)) = CREATE (DELETE (X)). 

But, DELETE (PUBLISH (CREATE (X))) is not equal to DELETE (CREATE (X)), 
because the intervening "PUBLISH" function defines a different version or configuration of the 
hypertext. 



RESEARCH AGENDA 

The working group concluded that research is needed in many cases to help define the 
appropriate semantics for hypertext functions, and it would be appropriate for NIST to conduct, 
sjwnsor, or encourage this research. Research is also needed to define new measures for 
hypertext that describe characteristics relevant to user performance. This research agenda should 
include research into these areas: 

Evaluating "hypertextability." While there are informal guidelines for determining 
whether a particular document or document collection is suitable for conversion to hypertext, 
more reliable and objective measures are needed. "Hypertextability" can potentially be 
characterized by aspects of the logical structure of a document, such as the number, size, and 
relationships of the information units. 

Validation of hypertext conversion. Measures of hypertextability will also be 
invaluable in hypertext projects for estimating the resources required and estimating schedules. 
Corresponding methods and tools for measuring the "amount of hypertext" that has been 
successfully converted should follow; perhaps hypertext sets of Hnks can be evaluated using 
analogues to the familiar ideas of "precision" and "recaU" in information retrieval. 



-34- 



Measuring hypertext "readability." Readability formulas for ordinary text based on 
sentence length, word length, or other characteristics have been a continuing subject of research 
[8]. Hypertext extensions to readability metrics might include measures of the "goodness" of 
links based on similarity between linked units. Readability measures for alternative hypertext 
designs for the same text will go far toward making hypertext design an engineering discipline. 

A final research area identified by the working group where progress will immediately 
benefit users involves intellectual property issues for hypertext and hypermedia. The rash of 
"look and feel" copyright infringement lawsuits and similar claims for software patents confront 
software designers and developers with chaos, uncertainty, and legal action [10]. But as unclear 
as the situation is for software in general, the novel character of hypertext and hypermedia 
software raises still more complexities for intellectual property law. For example, if copyright 
law has different rules for "literary works," "audiovisual works," "sound recordings," and 
"pictorial works," into what legal category does an interactive hypermedia encyclopedia or a 
talking book fall? Are new links or notes in a hypertext system considered "derivative works" 
under copyright law? These and other issues are not just legal curiosities ~ they will have 
considerable impact on the legal protection available and hence the economic viability of 
hypermedia systems. 

REFERENCES 

[1] Association for Computing Machinery. Hypertext '87 Proceedings. ACM: New York, 1987. 

[2] Association for Computing Machinery. Hypertext '89 Proceedings. ACM: New York, 1989. 

[3] Department of Defense. Computer-aided Acquisition and Logistic Support. Office of the 
Secretary of Defense CALS Office, The Pentagon, Room 2B322, Washington, D.C. 
20301. 

[4] Guttag, J. Abstract data types and the development of data structures. Communications of the 
ACM, 20(6), June 1977. 

[5] Halasz, F., and Schwartz, M. The Dexter hypertext reference model. Proceedings of the NIST 
Hypertext Standardization Workshop, Gaithersburg, MD, January 16-18, 1990. 

[6] Hypermedia. 1(1), 1989. 

[7] International Organization for Standardization. Standard Generalized Markup Language, 
ISO 8879-1986. 

[8] Klare, G. Assessing readability. Reading Research Quarterly, 1974-1975, 10, 62-102. 

[9] McAleese, R. (Ed.). Hypertext: Theory into practice. Blackwell Scientific, 1989. 

[10] Samuelson, P. Protecting user interfaces through copyright: The debate. Proceedings of the 
ACM Conference on Computer-Human Interaction - CHI '89, 97-103. 



PAPERS 



This section of the proceedings contains the twelve contributed papers which were 
accepted for publication and featured during the plenary session on the opening day of the 
workshop. It also contains the two papers which the interchange group recommended be 
added. 



-37- 



Hypertext Interchange Format 
— Discussion and Format Specification — 
DRAFT 1.3.4 
jeremy bomstein 
victor riley 



The Hypertext interchange format described here is based on the work 
of the Dexter group, an industry coaUtion of hypertext researchers interested 
in a standard for hypertext data exchange. This paper describes the result of a 
collaboration towards this end between Jeremy Bornstein and Frank Halasz, 
with significant input from other members of the Dexter group, most notably 
Tim Oren. The work took place during the summer of 1989, and a 
demonstration is planned for the Hypertext '89 conference in November of 
1989. 



backgroimd and rationale 

The number of hypertext platforms is increasing, not decreasing. 
Although this development will most likely settle down to a stable state, it is 
almost certain that no one platform will dominate the hypertext world to the 
extent that nobody at all will use an incompatible platform. Nevertheless, 
large bodies of hypertext data are being developed in systems which will 
either die or evolve. An interchange format allows users on separate systems 
to share their data, thus eliminating the need to acquire, learn, and use a new 
hypertext system only to access that system's data. 

Of course, in order to propose a reasonable interchange format, the 
structure of the data must first be determined. As it happens, with regard to 
hypertext this is by no means a closed issue. The Dexter group made the 
decision to describe a format which would be able to include everyone's 
definition of hypertext and thereby short-circuit "rathole" debates about the 
nature of hypertext, instead focusing effort on the structure of a given 
system's hypertext. The framework, described below, attempts to be an 
inclusive definition rather than an exclusive one. 



-39- 



generalities 

The format is an ASCII format, as opposed to a binary format. 
Conversion to a binary format is possible if desired, but a text format is much 
easier when the definition of the format is still evolving. 

The appearance of the format is similar to that of SGML^: there are tags 
marking the beginning of a hierarchical section and tags marking the end 
("begin-tags" and "end-tags"); the end-tag corresponding to a given begin-tag 
has a backslash ("\") in front of the name for the begin-tag. Tags appear 
between greater-than and less-than signs ("<" and ">"); if the greater-than 
sign appears in the data, it is doubled ("«"). The order of the children of a 
given tag is irrelevant^. 

Tags which are not understood by a parser are guaranteed to be ignored 
by that parser. In other words, if a particular system exports information 
which no other system understands (yet), then this will not cause another 
parser to crash, but merely render an incomplete version of the document. 

The characters A-Z, a-z, 1-9, and the underscore ("_") are the only valid 
characters which may be used in the name of a tag. Case is not significant. So 
far, the agreed-upon conventions are that tags begin with a lower case letter 
and that words after the first are marked by capitalization of the initial letter. 
For example, "thisHasFourWords" is a tag name which adheres to these 
conventions. 

Whitespace, when it appears outside of the data belonging to a bottom- 
level tag, is not significant. Often in examples, a single space character is 
added after bottom level start-tags and before the corresponding end-tags, but 
this whitespace is not in the actual export files. The indentation which 
appears in examples is also not part of the format, but it should not cause an 
interchange-format parser to fail. 

Since many references in a hypertext environment will take place 
across "document" boundaries, it is necessary to be able to reference many 
objects from a global standpoint. In order to make this independent of file 
name and directory position, global IDs are used. So far, the numbers are 64 
bit numbers which may be chosen by any method, preferably including at 
least some random bits. Eventually this may be changed in favor of some 
method which better ensures uniqueness of each identifier. 

specifics 



^SGML ~ Standard Generalized Markup Language 
^That is, the following two expressions are equivalent: 

• <foo> <bar> 128 <\bar> 

<baz> 256 <\baz> <\foo> 

• <foo> <baz> 256 <\baz> 

<bar> 128 <\bar> <\foo> 



-40- 



This section is a rather humorless and redundant description of the 
data format. It might be more efficient to read the sample file first and then 
refer below for confirmation and clarification of your understanding. The 
description which follows is hierarchical, as is the interchange format itself. 

<DOCUMENT> 

The outermost tag in a HIP-format document is the <DOCUMENT> 
tag. The <DOCUMENT> tag has four possible types of children: the 
<HEADER> tag, <NODE> tags, <LINK> tags, and <COMPOSITE> tags. 
<HEADER> 

The <HEADER> tag contains relevant information about the 
document as a document: the name, the unique id, which 
system it was exported from and on what date. 
<NAME> 

This is the name of the document in the originating 
system. The name is primarily for display to the user, but 
it is possible that it could be used in trying to resolve links 
as well. 

<ID> 

This is the unique id of the document, following the rules 
for ids given above. 
<EXPORTED> 

This tag contains information about the originating 
system and when the document was exported from that 
system. 
<FROM> 

This is the name of the originating system. 
<DATE> 

This is the date on which the document was 
exported. A standard format for the date has not 
been agreed upon. 



-41- 



<ACCESS> 

These are the access rights for the document set. In the 
case of Intermedia this is the web, for NoteCards this is the 
NoteFile, for HyperCard this is the stack. No format has 
been agreed upon. 
<CREATION> 

The <CREATION> tag tells the time of creation and the 

creator for the document. 

<BY> 

This is the creation author. 
<DATE> 

This is the date which the document was created. 
<MODIFIED> 

The <MODIFIED> tag tells the time of modification and 
the modifier for the document. A set of these can tell 
history for changes. 
<BY> 

This is the modifier author. 
<DATE> 

This is the date which the document was last 
modified. 

<NODE> 

The <NODE> tags in a document function as the wrappers for 
the text/ graphics /&c. A <NODE> has several parts: 
<USE> 

This tag is used to specify the location to the contents of 
the NODE. If two <DOCUMENTS> share the same 
<NODE>, the <USE> tag is used to specify the location of 
the shared data. 
<NAME> 

This is the name of the node in the originating system. 
The name is primarily for display to the user. 

<ID> 

This is the unique id of the <NODE> (see above). 



-42- 



<ACCESS> 

These are the access rights for the node. 
<CREATION> 

The <CREATION> tag tells the time of creation and the 

creator for the node. 

<BY> 

This is the creation author. 
<DATE> 

This is the date which the node was created. 
<MODIFIED> 

The <MODIFIED> tag contains information about who 
made the last modification to the NODE, and when the 
modification was made. A set of these can tell history for 
changes. 
<BY> 

This is the userid (or other identifying information) 
of the last person to modify the NC3dE. 
<DATE> 

This is the date which the node was last modified. 

<DATA> 

The <DATA> tag contains the <NODE>'s low-level data 
(text or a picture, for example). If the <USE> tag is used, 
this should be NULL. 
<runTiineStuff> 

The <runTimeStuff> tag contains information about how 
the <DATA> should be displayed; it is currently the tag 
undergoing the most revision. It is expected that much of 
the information within it, such as font name, will often be 
unusable in the imported-to system. Within the 
<RunTimeStuff> tag, the five tags below are the only ones 
currently defined. The last three will most likely be 
uninterpreted by any system besides HyperCard. 
<FRAME> 

The position of a NODE with respect to its parent^ is 
described by the <FRAME> tag. If the <FRAME> 
tag is absent, then the parent <NODE> is considered 
to be "immediately subsequent" to the previous 
<NODE>. This would be the case for multiple 
<NODE>s in a creamy hypertext system such as 
Notecards or InterMedia. Otherwise, the following 
two tags determine the frame: 
<SIZE> 

This is the size (x,y) of the node. 
<LOCATION> 

This represents the offset (x,y) between the 
parent's origin and the node's origin. If not 



■^The parent may be a <GOMPOSITE> node or null. 



-43- 



present, it is undefined and the importing 
system is free to set it arbitrarily. 

<fontSpec> 

The <fontSpec> contains information about the 

font of the data. 

<NAME> 

This tag contains the name of the font. 
<SIZE> 

This tag contains the point size of the font. 
<STYLE> 

This tag contains any style modifications to 
the font: i.e., bold, italic, underline, &c. 
<JUSTIFY> 

This tag contains the justification rule for the 
text: left, center, or right. 

<lockText> 

This tag is "true" if the user is allowed to modify 
the text of the item, and "false" otherwise. 
<STYLE> 

This tag, probably only interpreted by HyperCard, 
describes the frame for the <NODE>'s <DATA>. 
<originalType> 

This tag, also probably only interpreted by 
HyperCard, contains "button" or "field," depending 
on the original type of the object. 
<ANCHOR> 

There may be several <ANCHOR> tags within a given 
<NODE>. The anchor tags contain information about all 
anchors present within the <NODE>'s <DATA>. 
<NAME> 

This is the name of the anchor in the originating 
system. The name is primarily for display to the 

user. 

<ID> 

This is the unique id of the anchor and must be 
present. 



-44- 



<CREATION> 

The <CREATION> tag tells the time of creation and 

the creator for the anchor. 

<BY> 

This is the creation author. 
<DATE> 

This is the date which the anchor was 
created. 
<MODIFIED> 

The <MODIFIED> tag contains information about 
who made the last modification to the ANCHOR, 
and when the modification was made. A set of 
these can tell history for changes. 
<BY> 

This is the userid (or other identifying 
information) of the last person to modify the 
ANCHOR. 
<DATE> 

This is the date which the anchor was last 
modified. 

<LOCATION> 

This is the offset in bytes (O is the position before 
the first character) of the anchor texc. If the 
<LOCATION> is a pair of numbers separated by a 
comma (or a triple for 3-D space), this describes the 
text span already in Lhe <DATA>. If the 
<LOCATION> is absent, the whole <DATA> is the 
relevant text. 

<TEXT> 

This is the text which the anchor is attached to. If 
the <LOCATION> tag is a single number (i.e., no 
comma) then the text is inserted at that position. 
Otherwise, the text need not be specified. 
<runTimeStuff> 

The <runTimeStuff> tag contains information 
about how the <ANCHOR> should be displayed; it 
is currently undergoing revision. 
<VIEW> 

The <VIEW> tag contains information about 
how the <ANCHOR> could be viewed. This 
also specifies whether the <ANCHOR> is a 
2D or 3D view or either. Right now, this is 
application specific. 
<OBJECT> 

The <OBJECT> tag specifies the objects the 
<ANCHOR> is attached to. This covers 
multiple spans of text, or multiple graphical 
objects. Right now this is application specific. 

<LINK> 



-45- 



A <LENrK> holds all the information about a single bidirectional 
link. This may be expanded in the future to describe multi- 
headed and multi-tailed links. 
<NAME> 

This is the name of the link in the originating system. 
The name is primarily for display to the user. 

<ID> 

This is the unique ID of the link itself. 
<sourceNodeId> 

This is the ID of the node associated with the start of the 
link. 

<sourceAnchorId> 

This is the ID of the anchor (within the source NODE) 

from which the link originates. If unspecified, the link is 

from the whole NODE. 
<destinationNodeId> 

This is the ID of the node associated with the end of the 

link. 

<destinationAnchorId> 

This is the ID of the anchor (within the destination 

NODE) to which the link is bound. If unspecified, the link 

destination is the whole NODE. 
<CREATION> 

The <CREATION> tag tells the time of creation and the 

creator for the link. 
. <BY> 

This is the creation author. 
<DATE> 

This is the date which the link was created. 
<MODIFIED> 

The <MODIFIED> tag contains information about who 
made the last modification to the LINK, and when the 
modification was made. A set of these can tell history for 
changes. 
<BY> 

This is the userid (or other identifying information) 
of the last person to modify the LINK. 
<DATE> 

This is the date which the link was last modified. 

<TYPE> 

This is a string which describes the type of link; some 
examples: "Explanation," "Next," "Annotation." 
<COMPOSITE> 

A <COMPOSITE> tag is the framework within which frame- 
based systems such as HyperCard and KMS represent 
cards/frames. It contains an <id>, one or more <NODE>s, and a 
<runTimeStuff>. 
<ID> 

This is the <COMPOSITE>'s unique ID. 



-46- 



<mnTimeStuff> 

So far, the only <runTimeStuff> defined for a 
<COMPOSITE> is the <FRAME>. 
<FRAME> 

The <FRAME> represents the <COMPOSITES>'s 

size and relation to its parent. 

<SIZE> 

This is the size (x,y) of the connposite. 
<LOCATION> 

This represents the offset (x,y) between the 
parent's origin and the composite's origin. If 
not present, it is undefined and the 
importing system is free to set it arbitrarily. 

<NODE> 

This is the meat of the composite. See above for a 
description of this data structure. 



-47- 



Standards for hypertext source files: the experience of UNIX Guide 



P.J. Brown 

Computing Laboratory 
The University 
Canterbury 
Kent, CT2 7NF 
England 



-49- 



In real-world applications, it is rare that a hypertext system provides a complete solution. Instead 
the solution normally comes from a combination of a hypertext system with other tools. Thus, as 
Meyrowitz (1987) has argued in his powerful position paper "The missing link: why we're all 
doing hypertext wrong", one of the most desirable attributes of a hypertext system is diat it 
should fit easily into its environment, and allow a close interaction with other tools in that 
environment. 

There is now a movement towards standardisation in hypertext systems, in particular a proposal 
that source files for hypertext systems should follow a standard form so that material can be 
interchanged between different systems. The market forces pushing this standardisation effort are 
obvious, but we must ensure that new standards do not detract from the interaction between 
hypertext systems and other tools. At an extreme, a standard that made it easy for a hypertext 
system to exchange files with other hypertext systems but hard to exchange with anything else 
would be a disaster. 

Do we use text-files? 

Choosing a file format for hypertext systems is similar to choosing a file format for word- 
processing systems. Indeed many hypertext systems support a good repertoire of word-processing 
operations. Hypertext systems have the added needs of representing hypertext constructs and 
links. Hopefully any standard will encompass all documents, irrespective of whether they are 
created from word-processing or hypertext. For hypermedia systems, similar considerations apply 
to the other media, but this paper concentrates mainly on text. 

A basic choice is whether files should be a text-file. By a text-file we mean a linear sequence of 
text with embedded mark-up but with no embellishments such as file-headers, associated tables, 
embedded pointers, etc. 

This paper argues the advantages of text-files. The argument is based on experience with the 
UNIX implementation of Guide, which uses a text-file format. Most of the material is concerned 
with nitty-gritty practical experience rather than with any underlying theory, but standards cannot 
ignore these practical aspects. We shall start by emphasising the properties of UNIX Guide that 
influence its file format. 

UNIX Guide 

A central aim of the UNIX implementation of the Guide hypertext system is that it should fit well 
into a UNIX environment (Brown, 1989). Indeed it is this facet, more than anything else, that has 
caused UNIX Guide to be different from the implementation of Guide marketed by Office 
Workstations Ltd (OWL) which runs on Macintoshes and PCs. OWL Guide successfully fits into 
its environment, which is very different from UNIX and has a strong house-style that pervades 
most of the software that runs in that environment. 

UNIX Guide — and henceforth all references to Guide should be taken as UNIX Guide — tries to 
follow the original UNIX 'Small is beautiful' philosophy, though this philosophy has perhaps 
been weakened over the years to the less catchy 'Medium-sized is beautiful'. Guide cannot hope 
to provide all the facilities that users may want. Instead it should be good at one thing, hypertext, 
and use other tools to provide functions that they are good at. 

Characteristic features 

Every hypertext system has some characteristic features that set it apart from the herd. In the case 
of Guide there are three such features: UNIX orientation, which we have just discussed, late 
binding and the scroll model. 



-50- 



Guide's late binding philosophy is that fixing of hypertext links should be delayed to the last 
possible moment; this is normally at run-time when the link is selected for the first time. Late 
binding has a number of benefits, arising from the dynamic nature of links. 

The Guide author specifies a link by a symbolic name (e.g. 'Lesser-spotted woodpecker'). If the 
link goes outside the current file a filename is appended to the symbolic name (e.g. in /x/y/z'). 
The destination of a link is a Guide 'definition' with the same symbolic name as the link. When 
links are saved in Guide source files they follow this symbolic form — they are just a sequence of 
characters attached to the button-name that is the source of the link, and only at run-time do they 
cause a link to be forged (by searching for a definition that matches the given name). Late binding 
is therefore a force that makes source files simpler and flatter. 

The third characteristic feature of Guide is its scroll model. A Guide document is a continuous 
scroll, and when buttons are selected they are replaced in-lLne by the corresponding button- 
replacement, thus causing the scroll to grow and shrink as buttons are selected/deselected. 

Groups of buttons can be combined into larger units, called enquiries. In Conklin's (1987) 
terminology an enquiry is a region, which is replaced if any button within the region is selected. 
In page-based systems that have a single current page, e.g. HyperCard, the region to be replaced 
is always the whole current page. Enquiries offer more flexibility: in particular, at one extreme 
they can be made to encompass the entire current document. If this is done. Guide, 
notwithstanding its underlying scroll model, can be used to simulate these page -based hypertext 
systems. (See Brown (1990) for a discussion of a large application that takes advantage of this.) 
At another extreme the region of replacement can be made null: everything remains; if, in 
addition, a button is made to throw its replacement up in a new window (as Guide 'action-buttons 
can be made to do) instead of in place of the original button, then the end result has the flavour of 
NoteCards. Overall, therefore, the scroll model is not fundamentally different from a page-based 
one. 

Nevertheless the scroll model, with in-line replacement the norm, has influenced the source file 
design. For the simplest type of button, which has a fixed replacement that is associated with that 
button and no other, the button-replacement comes immediately after the button-name in the 
Guide source file. This simplest type is button is also generally the commonest, since it is used in 
hierarchical expansions. 

Guide source files 

Having covered Guide's characteristics we can now describe its source file format, and the 
advantages that come from using such a format. 

As we have said, the file format is that of a text-file: a sequence of text and graphics with 
embedded mark-up. The mark-up simply shows where Guide constructions (e.g. buttons, 
replacements, enquiries, 'ghosts' — Guide comments) begin and end. All the necessary 
information is carried by this mark-up: there is no file-header and there are no associated tables, 
etc. 

The mark-up follows the format of trojf requests. For example, a button-name 'Lesser-spotted 
woodpecker' would be represented as 

. Bu button-attributes 
Lesser-spotted woodpecker 
.bU 

Thus die Bu and bU requests mark the beginning and end of a button name, and the Bu request has 
as its argument a description of the button's attributes. (For better or for worse, attributes do not 
figure sfi-ongly in Guide and the Bu request is, in fact, one of the few Guide requests that has 
attributes.) 



-51- 



The purpose of this paper is not, of course, to propose fro^ format as a standard. As far as Guide 
itself is concerned it would be equally easy to replace the troff syntax with any other syntax that 
had mark-up embedded in the text, e.g. our previous example could have been in the SGML (ISO, 
1986) form: 

< Button ... > Lesser-spotted woodpecker < \Button > 

However, given the need to use other UNIX tools, the use of troff syntax, which is a UNIX 
standard, has certain advantages. For example: 

• spell, the UNIX spelling checker, can be used on Guide files without any adjustment. 
(It automatically strips off rroj^^mark-up by using the deroffniility.) 

• if Guide files are to be formatted and printed on paper, troff can do the job. For 
example the Bu request can be made a macro which, inter alia, switches to bold-face so 
that button-names come out in bold. (The names of Guide requests have been 
deliberately chosen not to clash with other r?7?^ requests.) 

These UNIX -dependent advantages of Guide's mark-up should not, however, be over- 
emphasized, and if SGML-based tools had been readily available SGML format would have been 
a better choice. 

Readability 

The majority of Guide users are unaware of how its source files are stored. However some authors 
do need to look at or to generate source files, and for them it is a huge advantage that the files are 
fairly readily understood by humans. Indeed the very first Guide implementation (1984-5) had a 
file format involving esoteric binary codes, and perhaps the greatest step forward in Guide's 
development has been the banishing of this mumbo-jumbo. Sample benefits of the readable form 
are: 

• it can be edited using speciahst editors. Although Guide offers editing, this is not its 
forte; elaborate editing, e.g. global replacement of a pattern, can be done by a tool that 
is specially designed for such tasks. 

• it makes conversion programs easier to write and debug, a point we discuss later. 
Other media 

Although this paper concentrates on text, since we believe it will predominate in most hypertext 
applications for the foreseeable future, it is not sensible to ignore other media. They can be either: 

(a) stored in separate files, whose names are referenced in the main text-file. These 
separate files would hopefully be represented in the appropriate standard form for 
the media. 

or (b) embedded in the form of comments in the text-file. Often the content of these 
comments will appear as arbitrary binary codes, sanitized if it is necessary to avoid 
'difficult' codes such as end-of-file and end-of-line. 

UNIX Guide offers both. If the second approach is used a bit-map picture is represented as: 



-52- 



.Pi 

. \" bytes representing binary encoding 
A" bytes representing binary encoding 



.pi 

Each line of the binary encoding is made to appear as a troff comment. This is important, as it 
causes utilities such as spell to ignore these lines; otherwise there could be spurious reports of 
spelling errors. 

In order to create the encoding of a picture, Guide has to capmre the raw picture in the first place. 
(The raw picture will typically have come from a drawing program or a scanner.) Like most other 
software, Guide tries to avoid input modes ('This is a picture', 'This is a text file'). Input modes 
can be avoided if files have a type associated with them. UNIX has a somewhat basic — unkind 
people would say crude — mechanism for attaching a data type to a file. This is the 'magic 
number'. It helps Guide avoid input modes though it becomes difficult if materia! comes in 
through a pipe rather than direct from a file. Overall a standard could not assume that every file 
system provides a satisfactory mechanism for attaching a data type of a file. Hence if source files 
are represented in a wide variety of forms, corresponding to different media standards, the user 
will sometimes be forced into the use of different input modes. 

Aims of standards 

It is worth pausing at this point to consider the purpose of hypertext standards. Three important 
aims of hypertext standards should be: 

(1) to allow import/export of documents, or more generally to allow sharing of documents 
with other software. 

(2) to allow exchange of documents with other hypertext systems. 

(3) to allow existing tools to be applied to standard documents. 

The last of these is often overlooked, but if there are no tools associated with a standard the 
standard will be a standard that no-one uses — a bitter lesson that many have learned. In most 
environments (and especially in UNIX) the vast majority of existing tools use a linear textual 
format. This may be a sad commentary on the state of the world, but it is the reality. Hence 
choice of a text-file fonnat as a standard has big advantages. 

One can argue on the relative importance of (1) to (3) above. Personally we rate (1) and (3) equal, 
with (2) far behind. We shall now discuss (1) further. 

There are two sub-cases of (1). Firstly there is the import/export case where material produced by 
another tool is converted to hypertext form or the hypertext form is converted for use by another 
tool. The other tool may be a word-processor, a database, a programming language compiler, a 
drawing tool, etc. Secondly there is the Utopia which the standard envisages: all material shares 
the same format and no conversion is necessary — though several problems remain, as we shall 
see later. 

Conversion may be done in advance or on-the-fly. The latter is, of course, preferred if conversion 
is a fast process, since it does not involve keeping two separate documents up to date. Conversion 
is normally a dreary and unsatisfactory process, but there are three ways in which the hypertext 
file format can help: 

• a simple textual format facihtates conversion. 



-53- 



• it helps if hierarchical buttons have their replacement immediately following. For 
example it then requires only a trivial effort, when converting a word-processor file, to 
map section headings into button-names and the body of the section into the button's 
replacement. 

• a format that is readable by humans aids the debugging of conversion utilities. (Sadly, 
conversion utilities, because of their ad hoc nature, tend to take a long time to debug. 
Each new source document brings a new crop of problems.) 

Pipes 

If conversion is performed on-the-fly the UNIX pipe — now available, in one form or another, in 
most operating systems — is a convenient way for transferring data. Hence Guide is frequently 
used as a component of a pipe. 

Following the general UNIX philosophy Guide does not know or care whether its input comes 
from a source file or a pipe and the same format applies to both. 

In this environment the following characteristics of source files have proved valuable: 

• source files are text-files — again this advantage comes first: most piping mechanisms 
are based on the stream-of -characters model. 

• a text-file containing no mark-up at all is a valid soiu-ce file. Such material (e.g. the 
whole or part of existing non-structured files) is commonly used in building Guide 
documents and does not, therefore, require a special input mode. 

• a concatenation of source files is a valid source file. Moreover a soui'ce file can be 
included within another. Thus a utility such as the C pre-processor can be used to 
build the Guide input from a combination of existing source files. (These may, indeed, 
be paranieterised using pre-processor statements such as define and ifdef.) 

Newlines 

A small issue of some importance is the treatment of newline characters, and in particular whether 
they should be hard or soft. Since newlines are hard in ordinary text files. Guide generally treats 
newlines as hard. However a newline that precedes a Guide request is ignored. (A newline 
preceded by a null Guide request therefore acts as a soft newline. When Guide saves a file it 
inserts a soft newline if an output line is getting too long — very long lines knock out many 
UNDC utilities.) Obviously, when material is imported or exported, soft newlines and other soft 
mark-up needs to be stripped out before transmission. 

Dynamic interchange 

Ideally a hypertext system should support a dynamic interaction with its environment. Thus data 
should be shared with other programs while the hypertext system is running. It is natural that the 
source file format applies to such data as well as to data that is pre-stored in source files. In Guide, 
the selecfion of a button can cause a program to be run, and the output from that program serves as 
the replacement of the button. This output follows the normal Guide source format; usually it is a 
sequence of ASCII characters without any mark-up. Sometimes, however, the output may involve 
hypertext structure: for example in one application, a button launches a program that is a retrieval 
system. The program searches for a given term and converts the hit list into a hypertext structui"e 
that makes it easy for the user to examine the hits rJiat seem most relevant. This structure is duly 
displayed by the hypertext system. In another application a button runs a program to produce a 
report of items currently in stock, and this output is produced in a hierarchical hypertext format. 

The issue of standardization also affects the programs that are executed within hypertext systems. 
Most systems contain their own programming language, and in HyperCard this is a major part of 



-54- 



the system. However experience suggests it would be hopeless to expect every hypertext system 
to abandon its current programming laiiguage and adopt a new standard one. 

Saving 

The 'save' operation from a hypertext system may involve: 

(1) saving what is seen. 

(2) saving what is seen, together with the hypertext structure behind it. 

It is (2) that interests us here, since it creates a hypertext source file. This output file need not 
relate directly to a single input file: at one extreme it could have resulted from loading several 
input (lies and editing them; at the other, the material saved could be a small fragment of an 
original input file. 

Cut-and-paste, when used to cut from the hypertext system, is a special case of saving. Ideally 
both (1) and (2) above should be offered, though Guide cmrently only offers (1). Case (2) is 
useful if the material is to be pasted back into a hypertext document. 

Saving may go directly to a file or into an output pipe. 

Saving presents no problem if source files use a text-file format. If the source format involves 
file-headers or the like, it requires more thought and perhaps more user action, particularly if the 
original input came from diverse sources. 

Sharing files 

EarUer in this paper we wandered in the anarchical world of conversion programs; it is now time 
to move on to the relatively Utopian idea of sharing information so that an identical file can be 
processed by many different systems. 

Let us assume that two programs X and Y share the same file. (X and Y may be different 
hypertext systems or one or other of them may be, say, a word-processing system.) A user of X 
may load the file, edit it and then save it. Cletu-iy the file should still be usable by Y. 

This apparently simple requirement requires care. Inevitably there will be some operations Y can 
do, but X cannot. Assume for example that Y can display text in different point-sizes but X 
cannot. If a file contains mark-up indicating a change of point-size X must preserve this 
information when a file containing point-size changes is loaded into X, edited and subsequently 
saved. As a greater challenge, X must behave sensibly when editing involves material that 
contains point-size changes: what happens if half of a siring in a large point-size is copied, and the 
instruction to increase the point-size is copied but the corresponding instruction to set it back is 
not copied? 

Guide currently makes an attempt to deal with these issues. It has an experimental system for 
sharing files with trojf. If a rroff file is loaded into Guide, Guide tries to take account of mark-up 
it can handle, e.g. new paragraphs; other mark-up. such as change of point-size, is ignored. 
However all the original fro^ mark-up is loaded into Guide in the form of 'ghosts' — comments 
that are only visible to Guide authors, not to Guide readers. When a Guide file is saved, these 
ghosts are converted back to the original troff maxk-up, thus re-creating the original file. Given 
that Guide authors can see these ghosts, they will, hopefully, be aware of the implications of the 
mark-up when they perform edits. 

On the other side of the sharing, when troff is using the file, there are fewer problems, not least 
because trojf has no save operation. It is, in this simation, a happy property of troff that it 
completely ignores requests it caimot recognise; thus Guide mark-up is ignored. 

Overall the current Guide sharing system just about works, but could profitably be replaced by 
something built on sounder foundations. 



-55- 



Errors 

If source files may be generated by conversion tools, editors, etc., they may well contain errors. 
The design of source files should therefore contain enough redundancy for such errors to be 
detected. The design should also bear in mind that, on detecting an error, the hypertext system 
should have sufficient information to give a decent error message and stop gracefully, retaining as 
much of the source file as possible. 

Abstractions and discipline 

The focus of this paper has largely been on the present rather nasty world. Ideally standards 
should look to the future as well as covering the present. 

Current usage of Guide (and doubtless of other hypertext systems too) has shown up two 
deficiencies: 

(1 ) a need for higher level abstractions than links, which are gotos. 

(2) a need for each application to evolve a hypertext house-style and to impose this. 

The two needs are related: many aspects of a house-style can be imposed by designing some 
special abstractions and then ensuring that authors use only those abstractions. This is similar to 
the way that document standards such as ODA (ISO, 1988) and SGML impose a general 
document architecture. 

The ICL Locator project (Meehan, 1987; Brown, 1990), one of the biggest current Guide 
applications, has successfully tackled (1) and (2) by producing a preprocessing tool for Guide that 
helps (and constrains) authors to produce the required Locator style. However preprocessors are 
not always the answer for the same reason that preprocessors to compilers for programming 
languages are not always the answer. In the latter case the program author, when 
maintaining/debugging a program, usually needs to be aware of its intermediate form and thus the 
power of the abstraction that the preprocessor provides is lost. 

Experience also shows that some environments want discipline and some want freedom. Tlius 
heavyweight mechanisms that affect everybody need to be avoided. 

Overall, therefore, it is desirable that soiu-ce file formats contain facilities for defining or imposing 
abstractions, but these should be optional. It should still be possible for draconian managements 
to enforce their requirements; for example, currently some managements do not release the real 
Guide to their authors, but equate 'Guide' to a UNIX shell-script which loads the real Guide with 
certain options already pre-set, and perhaps with some of the items in Guide's normal menu either 
suppressed or replaced. (Guide options are, incidentally, mostly controlled by UNIX environment 
variables and switches; some could profitably be controlled by mark-up within source files, but 
currently this is not supported.) 

Size of file 

The design of source file formats is somewhat influenced by the size of a typical file: is it a single 
'page' or could a whole encyclopedia be stored in a single file. In practice Guide authors vary 
considerably: some have tiny files and some have files containing megabytes of text. In the latter 
case there is a significant pause while the file is loaded but thereafter speed is superb. 

Typically the initial screen consists of a summaiy, which consists of a skeleton document with 
buttons representing the components of the document. Initially no buttons are expanded. 
However Guide's source file format, where normally the replacement of a button immediately 
follows the button-name, means that the whole source file needs to be loaded in order to paint the 
initial screen. Indeed because of this Guide always loads complete source files, making no effort 
to restrict itself to the parts that are actually needed. In the environment where Guide runs. 



-56- 



workstations with a lot of real storage, supplemented by virtual storage, this has caused no 
problems. However OWL's Guide, which can nm in much more constrained environments than 
UNIX Guide, has adopted a file format that does allow parts of the files to be loaded. OWL uses a 
structured tile format where associated tables designate where constructions begin and end. 

Conversion between hypertext systems 

Although UNIX Guide and OWL Guide have identical parentage and similar hypertext 
mechanisms, it would be a major job to convert source files between the two. This is not because 
file formats are different, but because there are significant differences in the way linking is done 
(e.g. UNIX Guide's late binding approach is not found in OWL Guide). 

A conversion has never been attempted but, if it were, it would be a similar exercise to converting 
between two somewhat similar programming languages: you may get an automatic tool to convert 
90% of a program, but the rest would need doing by hand. Even within the 90% that was 
automatically converted, there would be odd differences in program behaviour. 

A complete conversion between two radically different hypertext systems would clearly be harder 
still. It is not the source file format that is the problem, but fundamental differences in approach. 
This is why we believe that this is the area where standard file formats have least to offer. There 
is, of course, the possibility of a deeper standard which specifies how hypertext systems actually 
work. In practice there is, however, no more chance of getting creators of hypertext systems to 
agree than getting designers of. say, programming languages to agree. 

ConcSusions 

The tone of this paper has been at least lukewarm about standards. 

Nevertheless UNIX Guide can hardly claim to be a major force that will materially affect that 
standardisation movement, and hence standards may come. If they do come we hope they: 

• are geared to exchange with other software (word-processors, picture drawing 
programs, databases, etc) rather than specifically with other hypertext systems. 

• are geared to taking advantage of existing tools. 

• are based on ASCII files that can be read, edited, etc, by humans, and can be sensibly 
transmitted down pipes and similar mechanisms. 

• can treat straight text files as a subset of hypertext files, rather than as special cases. 

• are not based on a specific linking mechanism. If late binding is used, the linking 
mechanism is not very relevant to source formats. 

allow flexibility in the region of replacement so Guide enquiries and their equivalents 
in other systems can be supported. 

• cater for higher-level user-defined abstractions and house-styles. 

• allow other software to share hypertext files without the need for conversion 
problems. 

References 

Brown, P.J. (1989). 'A hypertext system for UNIX', Computing Systems, 2, 7, pp. 37-53. 

Brown, P.J. (1990). 'Hypertext: dreams and reality', in Lennox, G. (Ed.) 
Hypertext/Hypermedia and object-oriented databases, Kogan Page, London. 

Conklin, J. (1987). 'Hypertext: introduction and survey', IEEE Computer, 20, 9, pp. 17-41. 



-57- 



ISO (1986). ISO 8879 — Text and Office Systems — Standard Generalized Markup 
Language (SGML). 

ISO (1988). ISO 8613 — Text and Office Systems — Office Document Architecture (ODA) 
and Interchange Format. 

Meehan, D.P. (1987). Locator: a system for service-desk 8801 fault diagnosis, M.Sc. thesis, 
Kingston Polytechnic, Kingston, U.K. 

Meyrowitz, N. (1987). 'The missing link: why we're all doing hypertext wrong', position 
paper. Hypertext 87, University of North Carolina. 



-58- 



Standards: What Can Hypertext Learn From Paper Documents? 

Fred Cole 
Heather Brown 

Computing Laboratory 
University of Kent 
Canterbury 
CT2 7NF 
England 



1. Introduction 

Hypertext literature tends understandably to concentrate on what is new and to ignore, or take for granted, 
the properties of hypertext that are also present in paper documents. The purpose of this paper is to 
consider how the expertise that exists in standards and models for paper documents can be used to save 
effort when designing a standard for hypertext, and how to make hypertext and paper document standards 
compatible. Section 2 discusses some relevant similarities between paper and hypertext documents. 
Section 3 introduces relevent aspects of the Office Document Architecture (ODA) [1] and suggests ways to 
build on ODA to create a standard that combines the strengths of the two areas. 

2. Similarities between paper and hypertext documents 

2.1. The need to separate the logical structure and its presentation 

Although hypertext systems vary widely in appearance and functionality they generally have similar 
underlying document structures — directed graphs in which the nodes hold the content and the arcs 
represent links of various types. The way in which the nodes and links are presented on the screen, and 
what happens when a link of a particular type is activated, are peculiar to (and usually hardwired into) the 
hypertext system. 

If a standard for hypertext is to be effective, it must allow a hypertext to be created on one system and 
presented on another. In particular it must allow for the possibility that the receiving system does not have 
the capability to perform the presentation as intended on the original system. To do this it should represent 
separately: 

(i) the components in the underlying logical structure; 

(ii) the specification of presentation facilities on each participating system (including dynamic properties 
such as the actions allowed when hotspots are selected); 

(iii) a mapping from (i) to the relevant set in (ii) for each participating system. 

This separation of the logical structure from the method of presentation is not just an inconvenience needed 
for portability; it is a positive feature that can be used to give hypertext some of the advantages that were 
given to paper documents by generic markup and structured editors. 

Markup of documents intended for paper used to be, and in many cases still is, presentation oriented. 
Formatting commands are inserted into the document to request explicit presentation features such as 
moving the current print position or changing to a given font style or size. Generic markup, on the other 
hand, is concerned with the logical structure of the document — it marks portions of the content as 
belonging to particular named classes. The actual layout and presentation are bound to the name later 
(either by the publisher, using traditional markup, or by a computer formatting system). Generic markup is 
essentially for non-interactive systems. The interactive equivalent is the structured document editor, which 
works in a similar manner by assigning a named class to each document constituent and providing separate 



-59- 



'style sheets' to specify the presentation of constituents belonging to the class. The appearance of all 
constituents belonging to the class can be changed by altering the style sheet. 

In both cases the effect is to separate low-level presentation details from the logical document structure and 
content (as in (i) and (ii) above) and to allow or provide a means of binding the two together at a later stage. 
This late binding corresponds to the mappings in (iii) above. 

In the logical structure of the document the named classes should correspond to the function of the content 
rather than the method of its presentation ('title' or 'reference' rather than 'change to bold type', for 
example). Generic markup and structured editing are acknowledged (see [2] for example) to have many 
advantages including: 

making it easier to present the document in another style (that of a different publisher, for example) 
without extensive manual changes to the text — this is the paper equivalent of presenting a hypertext 
on a different system. 

helping to maintain a consistent style throughout the document, and making it easier to enforce a 
house style. 

• improving typographic quality by discouraging authors from dabbling in low level details and 
leaving the design of styles to experts 

forcing the author to consider the structure of the document. This usually results in a better structure 
— and could be particularly important for hypertexts. 

Where layout and presentation facilities are complex, this separation of the logical and presentation aspects 
of the document often results in considerable factorisation of information and consequently in reduced costs 
for transmitting a document. 

2.2. Links 

Paper documents have links — intra-document links to components of the logical structure ("see section 
3.5") or to part of a particular representation ("see page 27"), and inter-document links (bibliographic 
references). Each link (in a well-written document) is accompanied by some indication of what the reader 
can expect to find at the other end, or at least the reason the author has for directing the reader there. 
Hypertext differs only in that, instead of indicating the position ("page 27") of the remote object, it offers 
some means of automatically accessing and presenting the remote object. 

If a system is to be able to edit or reformat a paper document and still retain the integrity of its links, then 
each link must be represented at the logical level in much the same way as it would be in a hypertext. It 
might, for example, have a type, a reference to the identifier of a remote object and, associated with the 
type, a specification for how it is to be presented. 

2.3. Hierarchical structures 

In paper documents the logical components referred to above are typically arranged in a hierarchical tree- 
like structure. A book, for example, might contain chapters which contain sections which contain 
paragraphs. This structure is primarily a tree but it may be supplemented by link components that cut 
across the normal tree links and turn the structure into a directed graph. 

Although hypertext systems emphasise the links more than paper documents, their underlying models are 
similar. Indeed, several hypertext systems recommend or enforce a general hierarchical model to minimise 
the well-known problem of readers becoming lost [3,4]. 

To represent a hypertext within the hierarchical model for paper documents, we could start by assuming 
that the logical structure components referred to above might simply be the links and nodes of the 
document. In this case each node would be very simple, consisting of a single piece of basic information 
together with hierarchical and non-hierarchical links. The hierarchical links would form the basic tree 
structure, and the non-hierajchical links would be the link components. 

Most hypertexts could not be represented by such a simple structure, however, and there is a need for 
internal structure for a node. A finer granularity is needed, in which each node is structured hierarchically 
into a number of subordinate components (including links) representing paragraphs, parts of paragraphs, 
diagrams, buttons, hotspots and such like. The hypertext node thus becomes a subtree and this makes it 



-60- 



possible to represent the node in a way very similar to that in which we represent a page of a paper 
document (although in some cases the 'page' might be so large that it needs to be scrolled). Rules for 
laying out and presenting the components of the node could then be specified in the way they are specified 
for a page of a paper document. 

2.4. Style and the problem of getting lost 

As shown above a single node of a hypertext is similar in many respects to a page or logical section of a 
paper document, and it has long been recognised that the meaning of a page of information — and the ease 
with which this meaning is understood — is very dependent on the skill with which the page is laid out. 
Those unskilled in the art of typography are well advised to leave the design of the document styles to 
experts. For a hypertext, style would include the positioning and presentation of different types of button or 
hotspot as well as text and diagrams. The structures described above would allow all the sophistication 
used for laying out a page of a paper document to be applied equally to laying out a node of a hypertext. 

Early applications of the standard will probably be in automatic translators between existing hypertexts and 
the standard, in which case the separate logical structure and the late binding will initially be hidden from 
end users. It would be wise however to ensure that the standard allows for future improvements in 
hypertext. A reasonable assumption is that hypertext systems could learn design techniques from paper 
document processing systems, including the principles inherent in generic markup, in order to gain the 
advantages listed above and especially to help authors to improve the styles of their hypertexts. 

Well defined and consistent styles have a bearing on the problem of getting lost in hyperspace [4], the 
solution to which has often been considered to be a matter of giving the user a suitable overall graphic view 
(or map) of all or part of the document. There is reason to believe tliat this may not be the only or even the 
best method [5] and that perhaps good authorship may make it unnecessary for the user (including authors?) 
to be aware of the underlying directed graph. Well-designed generic styles could be a way of helping users 
with this problem. 

2.5. Compatibility between paper and hypertext documents 

It would be foolish to ignore the need to produce a paper version of part of a hypertext, and it also seems 
sensible to make provision for readers to have the advantages of hypertext navigation when viewing a 
document on the screen — even if the document is eventually intended to be read from paper. These aims 
could best be achieved by having a common underlying representation for the structures of both types of 
document, together with well designed ways of mapping those structures onto different forms of 
representation. It is not suggested, of course, that a document designed for paper would necessarily make a 
good hypertext or vice versa, only that a usable representation should be readily available by applying 
different presentation styles. 

3. A hypertext standard based on ODA? 

ODA is a standard for the storage and interchange of complex multimedia documents. The ODA document 
model is hierarchical and object-oriented. It caters for both source (processable) documents and output 
(formatted) documents. Currently ODA documents can contain three types of content (character, raster 
graphics and geometric graphics) but other types of content will soon be added. 

Several major extensions to ODA are already under consideration in the relevant committees and working 
groups. These include tabular layout, video material, the inclusion of data in documents — and hypertext. 
The SGML [6] community is also starting to consider hypertext extensions. It would be tragic if three 
separate hypertext standards emerged: one based on ODA, one based on SGML, and a completely separate 
one from the hypertext community. After several years of rivalry and backbiting the ODA and SGML 
committees are showing encouraging signs of working together, so there is some hope that these two may 
merge. 

The details and suggestions given below are based on ODA, largely because ODA currently includes 
graphics and images and defines a layout process to map from the logical structure of tlie document to a 
formatted form. However, the genera! principles could apply to SGML when used with DSSSL [7] which 
defines a presentation model for SGML documents. 



-61- 



The following subsections describe the features currently in ODA that make it useful as a basis for a 
hypertext standard and then the features that we believe must be added. These new features are needed to 
improve the ability of ODA to represent all the features of high quality paper documents, but are also 
intended to prepare the way for the hypertext extensions to ODA. 

3.1. What ODA can already offer to hypertext 

The following sections give a brief description of ODA as it applies to paper documents. 

3.1.1. ODA Document Architecture 

ODA provides a tree-like model of a document. The structure of the document is given by the shape of the 
tree, while the content, is stored entirely in the leaf objects. Aitributes provide information about the 
objects. A few of the most important attributes are introduced in the examples and discussion below. Only 
one needs to be mentioned at this stage. This is the content architecture attribute that defines the type of 
content for each leaf object and thus allows different types of content to co-exist within the document. 

An ODA document is described by two structures. The logical structure divides and subdivides the content 
of the document into logical objects that mean something to the human author or reader. A logical object 
may be a general item like a section, title, paragraph or reference. Alternatively it may be a specialised 
item like a telephone number or price, or a collection of related information like a list of companies selling 
a particular product. Only the lowest level objects, such as titles or prices, have content. 

The layout structure is concerned with a visible representation of the content. It divides and subdivides the 
content into page sets, pages, and rectangular areas within pages. Rectangulai' areas with nested areas 
defined within them are known as frames. The lowest level aieas are known as blocks and, by definition, are 
the only areas to have content associated with them. A frame might be used to represent a column of text, 
for example, with nested blocks for the content of individual paragraphs. 

Each document has its own specific logical and specific layout structure, but their creation is guided and 
controlled by generic document structures for that particular class or 'style' of document. These are sets of 
object type definitions (one set for logical objects and one for layout objects) that specify the types and 
combinations of objects allowed. In ODA terminology tlie definitions constitute the generic logical and 
generic layout structures for a document class. 

3.1.2. Examples of ODA Structures 

This section illustrates the structures introduced above by presenting snippets of the generic structures that 
might be used for a journal containing technical papers. It also introduces a few important attributes. 

The generic definition for each non-leaf object has an atixibute called generator for subordinates lliat 
describes how the object may be made up from subordinate objects. These indicate that subordinate objects 
may be optional (OPT), required (REQ), repeated (REP), or optional and repeated (OPT REP), and that a 
group of objects may occur in a given sequence order (SEQ), in any order (AGG), or as a choice where 
only one of the group occurs (CHO). The information given in these attributes provides a simple grammar 
for the primary structure of the document class. 

Figure 1 shows the generic logical structure for a single technical paper in the journal. It indicates that the 
paper consists of a compulsory title, followed by a compulsory author's name, followed by an optional 
abstract, followed by one or more sections. If the abstract is present it consists of a single paragraph. Each 
section begins with a subtitle. The 'REP CHO' conslruct indicates thiat the subtitle is followed by a series 
of paragraphs or lists occurring in any order. Lists consist of one or more list items. (In practice, a more 
complex structure catering for items like footnotes and diagrams would be needed.) 

The conesponding generic layout structure might define one page style for the first page of the paper, and a 
different style for all subsequent pages. Figure 2 shows the top level of such a structure. The Title page' 
contains a 'Header frame' representing an area set aside for the title, autlsor's name and abstract, and a 
'Body frame' for the start of the first section. The 'Continuation pages' coniain 'Continuation body frames' 
to hold the rest of the sections. (Again, in practice, further frames would be needed for items like running 
titles.) Blocks are not included in the generic layout structure but are assigned to pages and frames during 
the layout process as outlined below. 



-62- 



Paper 



SEQ 



TiUe 



Paper page set 



OPT 



REP 



Author 



Abstract 



Section 



Head 



Head 



SEQ 



Paragraph 



Head 









REP 






Subtitle 




CHO 






Body 
















j Paragraph 




List 






Body 




REP 














List item 



Body 



Figure 1 : Generic logical structure 



Paper 
page set 



SEQ 



OPT REP 



Title 
page 



AGG 











Header 
frame 




Body 
frame 



Contir 
pa 


uation 

ge 






Continuation 
body frame 



Body 



Head Body 

Figure 2: Generic layout structure 

ODA's layout process decides exactly where each item of the document is to be placed. It uses the specific 
logical structure, the generic structures, and the content architectures to create the specific layout structure. 
It works at two levels 

Content layout takes portions of content and lays them out into blocks. This stage is dependent on 
the content architectures involved and on sets of attributes known as presentation styles. 

• Document layout places blocks in frames or pages. This stage is dependent on sets of attributes 
known as layout styles. 

The content layout process thus deals with character sets and tlie fine positioning of items within blocks, 
while the higher level document layout process decides how to place the blocks within pages and frames. 

The document layout process is guided by three attributes whose values are shown in italics in Figures 1 
and 2. Layout object class is normally used to indicate that a major logical division of the document should 
be directed into a particular page or page set. In the example the logical 'Paper' has its layout object class 



-63- 



defined as 'Paper page set'. This dictates that each paper must be laid out in a single instance of the page 
set shown in Figure 2. 

Within a layout object class, the attributes layout category and permitted categories can be used to direct 
logical objects into different frames. If a leaf logical object is given a layout category name, it can only be 
laid out in a frame that has the same name as one of its permitted categories. In the example the only 
category names used are 'Head' and 'Body'. When the layout process tries to place the blocks 
corresponding to the title, author's name, and abstract (if present), it will look for a frame with 'Head' as a 
permitted category, and will therefore create a 'Title page' and place them in the 'Header frame'. But when 
it reaches rhe blocks corresponding to the contents of the sections it looks for frames with 'Body' as a 
permitted categor)', so it uses the 'Body frame' until that is full and then creates 'Continuation pages' as 
necessary in order to use the 'Continuation body frames'. 

When the specific layout structure has been created, it associates the document content with pages, frames 
and blocks. The two specific structures are related and come together at the level of the content. Figure 3 
shows a fragment of the specific structures for the beginning of a paper. It assumes the paper has no 
abstract and that the first section begins with three paragraphs, only one of which fits onto the title page. 
Figure 3 shows a neat one-to-one correspondence between logical objects and layout objects. This often 
occurs, but not always. Lx)gical content portions may, for example, be split between blocks (when 
paragraphs are split over pages) or concatenated into paragraphs occupying a single block. 



LOGICAL 
STRUCTURE 



Paper 




Title 



Author 



Subtitle 



Content 




Content 










Block 




Block 



Content 



Section 




I Paragraph 



Paragraph 



Content 



Paragraph 



Content 



Content 



LAYOUT 
STRUCTURE 




Block 



Figure 3: Specific logical and layout structures 



3.1.3. Providing Different Views of an ODA Document 

The previous section gave only a brief sketch of the ODA layout process, but it should be sufficient to show 
that the appearance of a specific logical document can be altered by judicious changes to its generic layout 
structure. As a simple example, deleting the 'Body frame' from the 'Title page' in Figure 2 would cause 
each paper to be laid out with only the title, author's name and abstract on the first page. There would be 



-64- 



no frame on the first page with 'Body' as a permitted category, so the first section would have to start on a 
new page in a 'Continuation body frame'. 

More radical changes to the layout can be achieved by altering the attributes that make up the layout and 
presentation styles. The attributes in these styles apply to logical objects, but the objects contain only the 
identifier of the appropriate style. The styles themselves are held separately. This provides a more concise 
document representation and allows the styles to be changed without changing the logical structures. 

The layout styles include the layout object class and layout category attributes (described in the previous 
section) and other attributes governing the selection of frames and the positioning of blocks within a frame. 
The same layout object attribute, for example, constrains the block containing the logical object to share the 
same frame as the block containing another specified object, while new layout object consu-ains the block 
containing the object to start a new frame. Offset and separation control the minimum spacing between 
adjacent blocks, and the relative position of blocks is dictated by Jill order which allows normal top-to- 
bottom positioning or traditional footnote positioning. 

The presentation styles guide the lower-level content layout process and thus affect the appearance of 
content within individual blocks. They contain different attributes for different content architectures. For 
character content, for example, they include attributes affecting the indentation of the first line, the distance 
between lines, and the initial font size. 

Changing the generic layout structure and the styles can lead to significantly different views of the same 
logical document. Page and margin sizes can vary, single or double column layout can be used, and 
paragraph spacing and font size can change. In particular, it is possible to cater for different 'house styles' 
by this means and to provide different styles for interactive editing and the final printed version. ODA is 
not as flexible as it should be in this respect because it has insufficient separation between the logical and 
layout structures. We are attempting to get this changed (see below). 

3.2. What ODA still lacks 

The structures and styles introduced above form a good basis for a flexible standard for paper documents 
and provide at least some of the requirements for a hypertext standard. We have identified a number of 
deficiencies in the ODA standard and have investigated changes to the standard that would overcome them. 
The changes are needed in order to improve the representation of paper documents but were designed with 
the aim of preparing the way for an extension of ODA to deal with hypertext. ISO/IEC JTCl/SC 18/SWG 
(the special working group responsible for changes to the standard) has already declared its intention to 
develop such an extension. We have explained the deficiencies and our suggestions for improvement in a 
paper [8] that is to be considered by the special working group in January 1990. Brief outlines of the 
deficiencies for which we have offered cures are given below. 

3.2.1. Separating logical structure from presentation 

One of the strengths of ODA is its attempted separation of the logical and layout structures, but this does 
not go far enough, so we have made suggestions to make it complete. If it is required to change the style of 
a document (to the house style of a different company or different publisher, for example) it should not be 
necessary to edit the logical structure, only to apply a different set of layout and presentation styles to create 
a different "view" of the same logical document. This facility to change the view without changing the 
document is part of the answer to the problem of exchanging hypertexts between different systems that 
have different presentadon capabilities or different presentation conventions. 

3.2.2. Comprehensive attribute inheritance 

The ODA mechanism for inheriting layout and presentation attributes, in spite of its complex algorithm for 
finding default values, is insufficient. If an attribute value is not specified for the object or its class then the 
value can only be inherited according to the object's position in the tree and not according to its class 
(chapter, list etc.). Our suggestion for supplying this facility is Uie addition of 'style tables' as described in 
[8]. The use of style tables enables the style inherited by an object (and therefore the way it is formatted) to 
depend both on its class and on its position in the document. This mechanism is valuable for hypertext 
representation, making it possible to distinguish objects of the same type that are in different states (open 



-65- 



and closed buttons for example) and can be extended so that it can specify changes of state (such as those 
that take place when a hotspot is selected) by changing the style table. 

3.2.3. Links 

In both paper and hypertext views a document designer must be able to specify the purpose of each link, 
and to specify how the layout process can express that purpose. In this respect the requirements for hnks 
are very similar to those for logical objects, so it seems reasonable to deal with them in the same way — by 
having classes for links. The class of the link should determine how and where in the document the link 
can be used, and it must be possible to specify the representation of the link in a way that depends on both 
the class of the link and also its position in the document. 

We discovered that a small number of additions to the definition of ODA logical objects allows a document 
designer to use those logical objects as links, with all the functionality described above. These additions do 
not in any way change existing definitions or change the validity of existing documents. 

3.2.4. Selective and multiple presentation 

ODA does not have a mechanism for specifying that a logical object should be ignored in the layout 
process, nor that it should be laid out more than once. A facility to ignore objects could, for example, allow 
a document to contain a reviewer's annotations without those annotations appearing in a printout, or could 
allow different versions of the document to be produced for different situations. To achieve this we have 
suggested a simple variation on the style table mechanism described above. This facility is obviously 
needed for hypertext because most of a hypertext is not presented at all until selected by the user. 

3.3. Extensions and Interactive Documents 

This section shows how the proposed extensions can be applied to screen based documents and hypertext in 
general and then looks in more detail at how they can be applied to two particular hypertext systems. 

ODA allows a measure of flexibility in the layout and presentation of documents, but different views are 
not a substitute for proper interactive facilities. The basic problem is that the ODA layout process is 
sequential and page based — and several attributes reflect Uiis. Any form of online editing requires 
extensions to the layout process to make it incremental and to allow the user to scroU around the document, 
but some more ambitious features desirable for screen-based documents are 

(i) An outline facility — to display selected (usually high level) items, such as chapter and section 
headings, and ignore other items. 

(ii) Pop-up displays — to allow the temporary display of additional information on demand. These can 
be used for the equivalent of footnotes, marginal notes, and glossary entries in paper documents. 

(iii) Folding — to allow sections of a document to be hidden behind a 'button' on the screen and revealed 
on request. Folding should be allowed to any level, so hidden sections can contain further buttons. 

(iv) A linkage facility — to enable users to follow links or cross-references automatically. 
Item (i) is dealt with by style tables that select objects by class and required level. 

Item (ii) is dealt with by changing to another style table to produce a pop up display and then changing 
back again when the display is no longer required. 

Item (iii) is an extension of item (ii). The layout process needs be able to display either the button or the 
item(s) folded behind the button. One way to do this is to have both the button text and the folded 
components as subordinates of the button object. The button is closed when a style table is applied that 
displays just the button text, and it is opened by applying anoflier style table that displays the folded items 
(and possibly the button text as well). 

Item (iv) could be done in several ways depending on the type of link. Three possibilities are 
Move the current point of display to the target object. 
Display the target object (or subtree) as a temporary pop-up item. 
Include the target object (or subtree) at this point in the document. 



-66- 



These can be achieved with a combination of style tables and links. The style table specifies whether on 
not to display the linked object. When the style table is changed the linked object can be displayed as a 
new layout object (like a card), as a pop up item, or inserted inline with the surrounding content. 

3 J.l. Modelling Guide Buttons in ODA 

Guide [9, 10] is a hypertext system that supports a hierarchical model of a document and also allows cross- 
linking of information. A typical Guide document presents the reader with a summary consisdng mainly of 
buttons. These can then be selected to reveal greater levels of detail as required. Buttons may be nested 
many levels deep. The reader selects only the buttons he is interested in, and if he finds he is not interested 
in the information revealed he can 'undo' the selection and fold the information back behind the button 
again. Guide is also a WYSIWYG editor. It allows the reader to edit the contents of the document and to 
add or delete buttons, thus becoming an author as well. The emphasis is on allowing the reader to tailor the 
document to his own requirements. 

The overall Guide model is similar to ODA's hierarchical model, but with the added concepts of 

(i) Folding logical items behind buttons. 

(ii) Allowing more than one button to access the same logical items. 

Guide's layout model is of a single long scrollable frame holding all content except temporary pop-up 
items. Using an ODA framework could enrich the Guide layout model. To show how the Guide model fits 
with ODA, we shall introduce two different types of Guide button and explain how they might be 
represented. (The examples use the UNIX version of Guide, which is similar to the version marketed by 
OWL for the Apple Macintosh [11] but differs in some details.) 

The commonest type of button is the replacement-button. When a replacement-button is selected, the 
button itself disappears and is replaced by information that may in turn contain further buttons. The 
replacement is inline, so surrounding text may be reformatted or scrolled out of the way to make room for 
the replacement. 

Figure 4 shows two different views of a Guide version of part of the ODA standard. In Figure 4(a) the 
visible text is made up entirely of buttons giving section headings. (By convention, Guide buttons appear 
in a distinctive font — typically in bold — so that readers can recognise them.) Figure 4(b) shows the 
result of selecting the 'Object Descriptions' button. Two further buttons are shown within the replacement 
The 'More' button is another replacement-button for the user to select if he requires more detail. The 
words in itaUcs are a different type of button known as a glossary-button. If the reader selects a glossary- 
button an explanation of the term appears temporarily in a separate window. 

To represent Guide buttons in an ODA document we would not set about defining a special new ODA 
object class for each type of button. Instead, for replacement-buttons, we would look first at the existing 
objects in a document class, decide which were appropriate as buttons, and apply style tables that would 
make them behave like buttons. Sections might be considered suitable for use as buttons, in which case the 
subtitle might be displayed as the button text, and the whole object displayed when the button is selected. 
Other classes of object (list items for example) might be modified for use as buttons by adding some 
abbreviated version as a button text component. 

There are several variations on the basic replacement-button. The simplest form is the local-button where 
the replacement applies only to the button itself. This is the default type described above. Two other forms 
are the definition-button and usage-button. For definition-buttons the replacement applies not only to the 
button itself but also to usage-buttons with the same 'name'. (Guide provides a mechanism for attaching 
names to the buttons.) It might be more efficient to mirror this in ODA by providing usage-buttons with 
button text and a link to the appropriate definition-button object. This then becomes a general mechanism 
for attaching the subtree containing the replacement content to several places in the document. 

Glossary-buttons are like footnotes, annotations, glossary entries, or other embellishments to the main 
document. Unlike replacement-buttons their replacement is not part of the main document, instead it is 
t>pically a short piece of pop-up text. We could represent glossar>'-buttons in ODA by defining a new 
'Glossary-button' generic object with a generator for subordinates specifying a button text item and a 
'Glossary-text' item. 



-67- 



2.3.2 Content portion descriptions 

2.3.3 Object descriptions 

2.3.4 Object class descriptions 

2.3.5 Styles 

2.3.6 Document profile 

2.3.7 Document class descriptions 



(a) Summary containing 
unexpanded buttons 
only 



2.3.2 Content portion descriptions 

2.3.3 Object descriptions 

Each object within a structure is characterised by a set 
of attributes called an object description. 

Each attribute has a value and may represent one of the 
following More 

2.3.4 Object class descriptions 



(b) Result of selecting 
'Object Descriptions' 
button 



Figure 4: Guide document showing (a) button and (b) expanded button 

'Glossary-text' would normally be defined as a simple leaf object with character content (to represent the 
explanation text). However glossary-buttons are intended to provide the same explanation for each 
reference to a term or item throughout the document, so it is attractive to think of a variation, similar to the 
usage-button, with a link to the appropriate explanation text. 

3.3.2. Modelling KMS Frames in ODA 

KMS [3] supports a data model based on workspaces known as frames. Frames may contain text, graphics 
and image items, and individual items within frames can be linked to other frames. There is no built-in 
notion of hierarchical organisation and no concept of a linear ordering of information. Information is 
divided into frame-sized chunks and one chunk is displayed in each window on the screen. The reader 
follows links to view different frames. 

In spite of this very general model, strong conventions have evolved for the format of frames and for 
distinguishing between hierarchical links and other links. Figure 5 shows the overall layout of a 
conventional KMS frame. (To avoid confusion this section will use 'KMS frame' and 'ODA frame' to 
distinguish the different meanings.) 

The generic logical objects defined to support a standard KMS database would correspond to the KMS 
frame and the items within the KMS frame. Figure 6 shows the top levels of a possible generic logical 
structure. 

The generic layout structure for a KMS frame would correspond to an ODA page with ODA frames 
representing the areas shown within the KMS frame in Figure 5. Layout object class would be used to 
direct each KMS frame into a single instance of this ODA page, and layout category and permitted 
categories would be used to direct the different logical items into the appropriate ODA frames. 

The 'tree' and 'link' items would be set up like the replacement-buttons described for Guide in the previous 
section. Thus 'tree' items would be like definition-buttons and would have two subordinates: the button 
text to be shown in their parent KMS frame and another KMS frame (to be shown if the button is selected). 



-68- 



Frame title 



Number 



Frame body 



Tree items 
Oinks to frames 
at next level) 



Link items 
(cross-references) 



Command items 



Figure 5: Layout of a typical KMS frame 



KMS frame 



AGG 



AGG 



AGG 









OPT REP 






OPT REP 




Frame 




Frame 




Tree 




Command 




Link 


id 




body 




items 




items 




items 



Frame 




Frame 




Button 




KMS 


tide 




number 




text 




frame 



Button 
text 



Figure 6: Generic logical structure for a KMS frame 

The 'link' items would be similar to usage-buttons. Tliey would have button contents to be shown in their 
parent KMS frame, and a link to the remote KMS frame. The layout process could be relatively simple as 
it only needs to display complete KMS frames and to follow the primary and secondary links to further 
KMS frames given in the 'tree' and 'link' objects. 



4. Conclusion 

A great deal of effort has gone into the production of the ODA standard and much practical experience has 
been gained. A new hypertext standard should not try to reinvent the wheel. We believe the best solution 
is to combine the existing expertise enshrined in the ODA (and SGML) communities with the expertise in 
the hypertext community. We must avoid having two or three separate standards and squandering the 
efforts of the few experts available. 



Acknowledgements 

We would like to thank British Telecom and the SERC for their support of research projects on document 
structures and ODA. 



-69- 



References 

[I] Information Processing - Text and Office Systems - Office Document Architecture (ODA) and 
Interchange Format ISO 8613-1988, International Org. for Standardisation, 1988. 

[2] L.Lamport, LaTeX user's guide and reference manual, Addison-Wesley Publishing Company, 1986. 

[3] R.M.Akscyn, D.L.McCracken and E.A.Yoder, 'KMS: A Distributed Hypermedia System for 
Managing Knowledge in Organisations' CACM, vol. 31 no. 7, pages 820 - 835, 1988. 

[4] J Conklin, 'Hypertext:introduction and survey' IEEE Computer vol 20, 9, pages 17^1, 1987. 

[5] P.J.Brown. X>o we need maps to navigate aiound hypertext documents?' Electronic Publishing — 
origination, dissemination and display, vol 2, no. 2, pages 91 - 100, 1989. 

[6] Information Processing - Text and Office Systems - Standard Generalised Markup Language (SGML) 
ISO 8879-1986, International Org. for Standardisation, 1986. 

[7] Information Processing - Text Composition - Document Style Semantics and Specification Language 
ISOIIEC DP 101 79, International Org. for Standardisation, 1989. 

[8] F.C.Cole and H.Brown, 'ODA modifications/extensions version 3', submitted to ISOIIEC JTCIISC 
18/SWG, January 1990. 

[9] P. J. Brown, 'Interactive Documentation', in Software — Practice and Experience, Vol. 16, No. 3, pp 
291-299, 1986. 

[10] P. J. Brown, 'A Simple Mechanism for the Authorship of Dynamic Documents', in Text Processing 
and Document Manipulation, ed J. C. van Vliet, pp 34-42, Cambridge University Press, 1986. 

[I I] Guide: Hypertext for the Macintosh, OWL International Inc., 1986. 



-70- 



standards for a Hypermedia Database: 
Diachronic vs. Synchronic Concerns 

Gregop/ Crane 
Perseus Project 
Department of the Classics 
Boylston 319 
Harvard University 
Cambridge MA 02138 

This paper outlines the perspectives of a professor in one traditional branch of the 
humanities (Classics). My colleagues and I are engaged in creating a hypermedia database 
on ancient Greek civilization, but our work is intended to explore the generic issues of 
building a complex hypermedia database, and Perseus was conceived as a model for what 
should (and no doubt should not) be done. We have encountered a number of problems 
along the way that must be solved before information disseminated in a hypermedia 
environment can have more than marginal impact on intellectual activity. This paper 
addresses h>'permedia databases: although much of our work revolves around texts and 
still images, we can see that sound, animation, and motion video are also basic categories 
of information. This paper at least views hypertext as a subset of hypermedia. 

The argument of this paper can be summarized simply. Standai'ds for hypermedia 
must emerge before hypermedia databases can be fully useful, but long-lived standards can 
only emerge after we know much more about how people will use hypermedia databases. 
Since we can do qualitatively different things in a hypermedia environment, we must 
assume that usage patterns will emerge. Practically speaking, we can expect to see short 
term interchange tools so that we can move data from one hypertext system to another, but 
we should be prepared to abandon these standards if they prove too inflexible. The rest of 
this paper outlines some pragmatic concerns. 

Standards can be viewed as working in two dimensions, synchronic and diachronic. 
Synchronically, hypermedia standards would allow all hypermedia systems at any one time 
to exchange and share information: thus, NoteCards, HyperCard, Intermedia, HyperTies, 
Guide etc. could aU exchange the same data. Synchronic standards ai'e, in some measure, 
feasible, and are a crucial first step. This paper, however, focuses on diachronic 
continuity: the same hyperaiedia database must be equally useable now and for many years 
to come. In fact, any hypermedia database that fits cleanly into any existing hypermedia 
system will probably not long survive. Synchronic standards will provide us with 
experience and knowledge that we can use to create truly diachronic standai-ds. If we are 
lucky, synclironic will evolve into diachronic, without shaip breaks in continuity. 



-71- 



For many, synchronic is more important than diachronic continuity. We do not need 
to preserve for centuries all the product documentation for every computer system available 
in 1990. Even a 1970 paper on new directions in punch card technology, for example, 
would have little appeal to the engineer today. The Historian of Science may some day 
wish to study this technology, but we cannot preserve everything. In such areas, 
information must be disposable. 

The notion of disposable information has profound implications. If one's ideas wiU 
only be valuable for five or ten years anyway, then the author may not care very much if 
those ideas are stored in a hypermedia system that is itself equally ephemeral. Press, an 
early hypertext system released at Brown in 1971, was demonstrated at Hypertext '89, but 
it appeared there as an historical artifact rather than a living system (its official title was "A 
' Blast from the Past: The Last (?) PRESS Demo". For others with a potential interest in 
hypermedia such as textbook publishers, short-lived systems are ideal, since they can thus 
attack the used-textbook market and force students to buy new electronic "textbooks" with 
greater regularity. 

It is hard to emphasize how destructive such attitudes are. True publication, however, 
implies that a document will be part of the public record for an indefinite period of time, not 
just for a few years. In many disciplines no scholar can afford to lavish time on creating 
documents that will not last at least thirty years and, hopefully, much longer. This holds 
true not just for humanists creating tools such as critical editions of authors (e.g., Homer, 
Chaucer), dictionaries and commentaries, but for many other areas as well. 
Anthropologists, for example, working in Central Africa or Latin America have their own 
questions in mind, and their own conclusions may soon become dated. But they also 
create ethnographic descriptions of societies that are rapidly changing. Their pubUshed 
ethnographies may be our best (even our only) records of those societies, and these must 
become permanent part of our information infrastiucture. We are constantly adding to our 
basic record of the world, and this record must be mamtained for an indefinite future. 

The author who creates information and the system that stores that information are 
only two aspects to a larger whole. Consider, for a moment, one other critical group that 
must also embrace the idea of hypermedia and for whom longevity is even more important. 
The librarian must be able to leave information "on the shelf' for centuries rather than 
decades. No document will last long if it is not presei'ved as a regular part of our research 
library system. I would like to emphasize that a standard that does not meet the most 
stringent needs of research librarians is, at best, a crude stopgap and, at worst, quicksand 
that will trap and overwhelm the unwary, and that will make subsequent travellers view 
hypermedia with distrust. 



-72- 



The problem from our perspective may be summarized as follows. Hypermedia 
systems offer tremendous potential and may ultimately revolutionize the way in which 
research is performed and disseminated. Hypermedia cannot, however, have the impact 
that it waiTants until we can provide diachronic continuity. A database that runs on ten 
systems now (and thus provides synchronic continuity) and zero systems a decade from 
now does scholar and librarian little good. 
Problem 1: Exchanging Data 

Exchange standards offer one obvious approach to the problem of diachronic 
continuity. If we can exchange database Fred between N different systems at any one 
given time, then there is a high probability that Fred will be able to move into new systems 
that have not yet appeared. Fred may not take advantage of all the capabilities of its new 
environment just as a black and white silent movie does not exploit the full capabilities of 
the television on which it may be viewed, and in some ways performance in the new 
system may be weaker (e.g., video has inherently less resolution than any film and thus 
cannot reproduce all the information in any one frame of the film). But at least Fred, like 
the silent movie, will still be accessible. 

Converting hypermedia databases from one system to another is much more complex 
than transferring silent film to video, more complex, perhaps, than the problem of 
converting a play into a movie. For while the play and the movie have profoundly different 
options open to them, the script of the play (in most cases) provides a common linear path 
which both can share, and a movie can imitate the conventions of the stage. 

The conversion from one hypertext system to another may well prove more analogous 
to the problem of machine translation. Existing hypermedia databases and even standards 
for particular types of information (such as the SGML standard for text) are generally 
closer to syntax than semantics. They illustrate how various objects are put together, but 
they can only incorporate a limited amount of information about why the objects are put 
together in that particular way. The designers of the hypermedia database will 
unconsciously tend to rely on the peculiarities of the system that they are using. Authors 
organize their data differently when using a system in which scrolling windows can contain 
large documents (e.g. Intermedia, Notecards) than when working witli an inherently 
"chunky" hypertext system (one built around many small cards) 

Consider two examples: 

1) HyperCard can easily store a hierarchical map. The user begins with a view of the 
world, zooms into a view of a particular country, and then calls up the plan of a particular 
city. A user can implement such a map easily with buttons containing goto's, but will an 



-73- 



interchange program be able to recognize that these buttons represent, in fact, a logical 
hierarchy? If the interchange program cannot make such inferences, will it produce results 
like the machine translation system that interprets "time flies like an arrow" as "time-flies 
enjoy arrows" or as "time the flies (i.e. with a stopwatch)". If hierarchical structures of one 
kind or another are to be a building block for hypermedia systems, then all such systems 
must contain primitives that recognize these structures. 

2) Much discussion has gone into the creation of links between anchors in various 
documents. Document X would have a link to an anchor in Document Y, and the anchor 
would identify a particular point or selection in Document Y. This is a critical and generic 
concept, but, in some contexts, it replicates a function that text strings implicitly perform: 
e.g. "Shakespeare Macbeth 1.7.1-2 'If it were done .... quickly"' defines a precise 
subset of the text. The text string is a high level construct that does not depend upon 
anchors into one particular document: it wiU work equally well whether the Riverside 
Shakespeare or the Folger edition of Macbeth is online. Does an automatic linking protocol 
really constitute an advance over such a reference, or even over a standard journal reference 
(e.g. "HSCP 91 (1987) 175 note 60")? If document (or an object in a museum for that 
matter) does not already have an anchor of this kind, then that information has not been 
published in any meaningful sense. Publication presupposes the existence of canonical 
citation schemes. Where canonical citations schemes do not exist or are imperfect, then 
information, like a misshelved book, is lost. 

Second, publication (as in Augment) cannot be retracted. A statement, once it has 
been placed in the public domain can never be changed: it can be commented on, and its 
author may recant, but the statement must remain a part of the record. A publication system 
(as opposed to an authoring system) should not accept vanishing links. 

New products such as SuperCard and Plus do attempt to interpret all the information 
within a HyperCard stack, but only because their own model of the world is a superset of 
the HyperCard model. Once a document is truly converted to either SuperCard or Plus: 
i.e., once it takes advantage of elements in the SuperCard or Plus model that are not 
available in HyperCard) then it cannot easily move back to HyperCard or even laterally to 
from SuperCard to Plus or vice versa. As soon as hypermedia systems begin to change 
their view of the world, then different systems will have different abilities. Translating 
from one environment to another becomes an interpretive act, in which human intelligence 
may prove irreplaceable for the forseeable future. 

The rest of this paper will cover problems that we in the Perseus Project have 
encountered in building a hypermedia database on ancient Greek civilization. The domain 
is relatively compact: 40 and 100 megabytes of source texts in original Greek and English 
translation, a dictionary, a small encyclopedia, essays, maps, plans, and 5,000 to 10,000 



-74- 



images of Greek sites, monuments.and art objects will provide a solid foundation for the 
study of this subject. Nevertheless, the problems inherent in managing such a 
heterogeneous database of this magnitude are substantial. 

More importantly, this data is intended to serve a wide audience. First, it aims at 
different levels of expertise: the undergraduate in a general course and the professor doing 
research. Second, it aims at various kinds of expertise: the same data should be useable 
for the study of literature, art, history, linguistics and other subjects. In fact, both 
distinctions are related: the more accessible information about art is, for example, to the 
freshman, the easier it can be for literary critics, who do not now have easy access to that 
information, to use it in their work. 

Our work is, to a large extent, an experiment within which we are trying to identify the 
basic data structures with which people work. Objects such as dictionaries, atiases and 
museum catalogue entries have evolved certain fairly stable forms that are based on 
functions that people seek to perform. As these tools migrate into an electronic 
environment they can perform new functions and their forms will inevitably change. Until 
we have a better idea of what these new functions will be, however, we are not in a good 
position to build environments in which the form of information can evolve. 

Data Models and Approaches: Some Concrete Problems 

Every discipline probably has its own proprietary data models which every expert 
must intemalize. Thus, the mathematician must know how to create and present a logical 
proof, while the chemist needs to provide certain kinds of information when describing an 
experiment. The student of ancient Greek literature knows how to read and to use a 
scholarly edition of a Greek text, while the archaeologist knows how to work with objects 
discovered on a dig. Hypermedia standards must provide a model in which each group can 
express as many significant features as possible. They must at least replicate the 
functionality of printed texts, but should also allow people to perform new operations. 

Defining a data structure is not an easy task. Even if we have a model that satisfies 
one group, another group may want to use the same information in different ways. The 
following section provides two general examples of the iterative process that we have had 
to undergo. The examples are fairly specific but they illustrate how difficult it will be to 
define what some people have in mind when they think about such basic categories as 
archaeological objects and source texts. Tlie problems below are very specific, and domain 
experts in various fields will have to create the actual specifications for these data 
structures. Nevertheless, the standards that evolve for hypermedia databases wiU 
determine how feasible it is for the domain experts to organize their information. The more 



-75- 



effectively authors can organize their data, the more useful the underlying standards will 
prove. Particular and domain specific as these problems may seem, they address 
fundamental data types. Until hypermedia standards provide a platform that supports such 
data types, hypermedia cannot play a major role in the publication or the long term 
archiving of information. 

The classicist discussing Greek religion may, for example, use the painting on a Greek 
vase as evidence. He may point out that there is a man is leading a bull to an altar, that the 
man holds in his hand a sacrificial cake and some barley to sprinkle over the victim. He 
may draw attention to the kind of knife held or some other particular of the scene. In this 
context, a single one bit deep bitmap may well contain all the information necessary, and 
the expert in Greek religion might want to collect a large number of such images. 

The art historian might want to study the style of the painter who created the picture. 
He would need to study very subtle details (such as the way in which anatomical details 
such as eyes or knees were rendered), but such detail will almost certainly lacking in the 
bitmap. The classicist can build up an enormous database of images which then prove to 
be of Uttle use to his or her colleagues in archaeology or art history. 

Worse, the art historian may actually conclude that one bit deep images are all that the 
computer can offer and thus turn away from the new medium. Likewise, many videodiscs 
(to choose one technology) simply imitate image libraries, even though a single video 
image cannot approach the clarity of a 35 mm sHde. The art historian may thus conclude 
that a videodisc s just a poor substitute for a slide archive, but if the videodisc designer 
takes advantage of the storage space, then he or she can store multiple views of each 
complex slide and can provide much more information. A videodisc that stores details of 
every head in a series of paintings contains information that the slides do not, for the abiUty 
to move directly from head to head to head allows tiie reader to see the images in a different 
way than would the undifferentiated slides. In the case of images, the media available to us 
so far have been so primitive, that few of the scholars who really care about art, for 
example, have been able to see much promise in electronic databases at all. 

Suppose, then, one builds up a database that serves the needs of both the classicist and 
the art historian. Thus, when we in the Perseus Project, for example, commission new 
photography of an art object, we collect multiple views: dozens for a single vase with many 
figures. A videodisc thus will have enough color \iews so that it will allow scholars to see 
more detail of the objects on the disc than could any affordabe printed publication. 

The case is not, however, closed. Up come the anthropologists, also expert in 
handling physical remains. For them, the detailed views are extremely useful, but they 
want to reconstruct day to day life of the period. The database of images focuses primarily 



-76- 



on the most elegantly painted and attractive vases: the art historian wants to study the 
aesthetics of classical Greece; since carefully drawn and visually harmonious vases contain 
much of the information that the general classicist needs, the two groups work well 
together. The anthropologist wants to see what people actually used, not just the most 
polished specimens, but the coarse, hurriedly drawn pieces as well. Perhaps, he does not 
even want vases in particular, but tools and other objects that illustrate the kind of work that 
people performed. Again, the invidual entries for each object may be quite attractive, but 
the anthropologist might argue that the collection as a whole provides a biased picture of the 
ancient world. Nor are the anthropologist's complaints necessarily limited to gross 
selection of objects: he or she have very different kinds of questions that they are going to 
ask and if a database is going to serve theu' interests, then its structure will undoubtedly 
need to be changed. 

Literary texts offer similar problems, for different groups view texts in different ways. 
The text of Moby Dick, for example, is conceived of as a fairly stable text stream. The 
critic will refer to a particular chapter or perhaps a page in a particular edition, but what 
Melville wrote is clear enough. It is relatively easy to build a publication model for "text" if 
we think in terms of nineteenth century English and American novels (and if we do not 
think too deeply about the problem). 

CHECKED UP TO HERE. 

If we apply this concept to a text that was transmitted in manuscript, this model is 
inadequate. Every time a large document is copied by hand, mistakes appear, and these 
mistakes become compounded with each new copy. Over the course of centuries, many 
variant forms of the text evolve and only with the printing press can this process of 
dissolution be arrested. Nevertheless, the damage is done: editors must choose between 
many competing variants, and must tell the reader when they choose a reading from 
manuscript X or Y, The reader needs, at a minimum, to see what variants are available for 
any passage of text. Ideally, the system should be able to show the reader where editor A 
chooses different readings from editor B, or to show, for example, which corrections in the 
text were suggested before 1800. 



^^^^aniiscript 0 



Scholarly 




Edition 





Manuscript 1 J 



—ii.rBMii ■■■wimiwumMUPiiiaiii^^'^t— I 

Manuscript n 



-77- 



Figure 1: Simplified view of a scholarly edition derived from 
various "manuscripts". Every line of text may involve an 
"editorial selection." 

Again, addressing both the nineteenth century novel and ancient Greek literature forces 
us to broaden our model of what a text is. Nevertheless, we are not finished. Consider a 
popular text that appears in various forms over a number of centuries. In the case of the 
Greek poet Aeschylus, for example, we assume that there is an original source text (i.e., 
what Aeschylus aclaially wi-ote) that we are trying to reconstruct. Ideally, we could treat 
Aeschylus like Melville if we had an authoritative edition of Aeschylus. In the case of a 
popular story, we may have multiple versions, none of which is associated with any 
dominant owner and each of which is essentially just as important as the others. Each 
version of the story may itself have its own manuscript tradition, but now we must 
consider a kind of compound versioning: a story consisting of multiple versions each of 
which has numerous textual variants. 



Figure 2: A compound text, consisting of n scholarly texts (each 
of which may be constructed from a variety of manuscripts). 

On the other end, even the category of "manuscript" is not completely simple. A 
document may be preserved on a stone or clay tablet. The writing system used to store this 
text may be crude, and scholars may need to provide normalized transliterations that follow 
conventional spelling rules or add some standard kind of information (thus many editors of 
Greek inscriptions add accents to theii; final editions). In such cases, an edition may 
include (1) a picture of the inscription, (2) a transliteration of the inscription without accents 
or word breaks that simply, (3) a regulariized form. The physical medium may be stone or 
(as in the case of much AJckadian and Sumerian material) clay tablet, but in many ways the 
problem is similar to that faced by someone transcribing a sound recording made by the 
speaker of a little known language. The ethnographer may well want to include a narrow 






-78- 



phonemic transliteration. Thus, we might outhne the structure of a source document (of 
which a "manuscript" is one example) as: 



Normalized 




Narrow 


Transliteration 




Transcription 



- | Recording 



Picture of 
Inscription 



Sound 
Recording 




Figure 3: Diagram for one taxonomy of source documents (such 
as a manuscript or inscription). 



This diagram presents a basic data model that will solve many of the problems for 
storing nineteenth century novels, Greek plays, Akkadian myths, Greek and Akkadian 
inscriptions, and an anthropologist's verbal recordings made in the field. 

The particulars of this simpUfied model are less important than the process that led to 
its creation: had we standardized around the nineteenth century novel, the Greek play or 
the inscription, we would have adopted an impoverished data model. We need to view in 
as much detail as possible as many different kinds of text as we can before we assume that 
we know what a text is or what it can do. A system that can handle these functions must 
address links not simply from one document to another, but between text, pictures, sound 
and motion video. Until we have systems that actually perform these tasks, we will not be 
sure that our standards actually account for the problems that people need to solve. This 
kind of analysis has barely begun, and we have a long way to go before we reach any 
consensus as to how any basic categories of informadon should be organized. 
Hybrid Data models 

So far we have talked about simple data types that have analogues in the world of 
print. We can insulate the individual components of data from the vagaiies of any one 
system by storing information in the most powerful medium possible. Thus, we at Perseus 
have pragmatically chosen to expend extra effort so that our information will be useful for a 
longer period of time: drawings are stored not as bitmaps but in Postscript; for still images 
we use 35 mm film rather than video. A single Postscript can generate multiple bitmaps at 
varying resolutions, and whatever the future of Postscript itself, subsequent graphic 
formats will probably be able to absorb most of the existing Postscript data. We will thus 
be able to upgrade our site plans and drawings to systems that do not rely on bitmaps. 
Slides, though not electronic, contain far more infonnation than we can now reasonably 



-79- 



store in digital form. Should new formats such as HDTV actually arrive within the next 
five to ten years, film will convert much more elegantly than inherently crude NTSC video 
signals with their limited resolution. None of the hypermedia or hypertext systems 
currently available can recognize sophisticated text structures that one can create in format 
such as SGML, but we store our texts in SGML and will be able to take advantage of more 
powerful hypertext systems as these emerge. 

Efforts are ab"eady underway to provide workable standards in at least some of these 
individual areas. The Text Encoding Inidative, funded primarily by the NEH and EEC,^ is 
a widely supported effort to build basic document formats for humanists within the 
framework of SGML. Storing images as slides or as postscript drawings is a pragmatic 
hedge rather than a workable standard. 

Work on texts or images in isolation is only part of the problem, for these are only 
some of the basic components out of which a hypermedia documents might be constructed. 
Once we know how to handle these individual pieces, a hypermedia system must then be 
able to make the individual pieces work together as a whole. If an historical source text, an 
atlas and a database of topographical images (i.e., pictures showing buildings and places) 
all exist in the same database, then it can become much easier for the person going through 
the historical document to locate places on a map and even to call up images of what that 
place looks like now. Someone, for example, reading in the Greek historian Herodotus 
about how the Greeks defeated the Persians in the battle of Salamis might thus call up a 
map on which Salamis appears, then view color images of the strait in which the battle was 
fought or the hilltop from which Xerxes, the Persian emperor, viewed the battle. 

Once traditionally discrete bodies of knowledge such as text, atlas and image archive, 
can dynamically interact with one another, then new compound document types become 
feasible. A narrative on the batde of Salamis might consist of (1) links to the relevant text 
sources, (2) a map of Salamis with various buttons which were in turn (3) links into the 
image archive showing what the strait of Salamis or the hilltop of Xerxes looks like. Nor 
should such links be entirely passive: an animated version of the battle could be overlayed 
onto the generic map. Rather than calling up an entire picture, the system should be able to 
crop a particular detail, so that the view frames that particular hill, for example, on which 
Xerxes may have sat. A document may dynamically abstract and shape data from a larger 
data base. 

Such interactive and dynamic links fulfill logical needs and will inevitably become pait 
of tiie autiior's repertoire. An autiior should be able to create a document tiiat pulls together 

^The Project Director for this is Dr. C. Michael Sperberg-McQueen, of the University of Illinois at 
Chicago Circle. 



-80- 



and performs operations on material in a larger database. It is not enough, however, to be 
able to perform such actions in a particular system in a particular time. Once an author has 
published such a hypermedia document (perhaps as part of a book interpreting the wars 
between the Greeks and Persians), then scholars a century later must be able to view that 
hypermedia document and see exactly what the author saw. If this diachronic continuity is 
not feasible, then the hypermedia document may have been distributed but cannot properly 
be said to have been "published". True publication implies that the material will remain 
available for the indefinite future. 
Conclusions 

We should move as quickly as we can towards some kind of synchronic interchange 
standard for hypermedia. We need to learn how well we can move fairly complex sets of 
data and functionality between diverse systems (e.g. HyperCard, Intermedia, Notecards). 
Once we are able to perform this task for some data, we may well decide that the 
interchange format that developed is, in fact, too inflexible. With luck, this interchange 
format will be a powerful platform that can evolve into a standard that wiU provide scholars 
and archivists with the diachronic continuity that they require. We must, however, be 
prepared to discard that format. 

The risk is probably greatest for those of us creating databases: until we have 
diachronic standards, the information that we create may be available in libraries, but it will 
not be part of the library system. It will be distributed, but not truly "published." 
Nevertheless, we cannot make much progress on standards without applying them to 
substantial and fairly complex bodies of data. 

From a practical point of view, we suggest that those developing interchange standards 
should plan to work from the beginning with one or more databases at least as large and 
complex as that of the Perseus Project. An interchange system that can move this database 
back and forth between three or more different hypermedia systems may not be perfect, but 
an interchange system that cannot satisfy tliis practical requirement will certainly not 
support the much greater challenges that it will face. 



-81- 



The Trellis Hypertext Reference Model 

Richard Furuta* and P. David Stotts 
Department of Computer Science 
University of Maryland 
College Park, MD 20742 



Abstract 

We describe a hypertext "meta- model" — one that provides an organization for the architec- 
ture of a hypertext model. The specific meta-model presented was developed in the context 
of the Trellis hypertext model. However the organization seems generally applicable to other 
models as well. As such the meta-model may be a good candidate for a hypertext reference 
model, and so we call it the Trellis hypertext reference model. In this report we first describe the 
Trellis hypertext reference model, and then discuss the relationship of some hypertext-defined 
concepts to the reference model. 

1 Introduction 

As a side-product of our work developing the Trellis model of hypertext [SF89a], we have defined 
a "meta-model" that provides an organization for the architecture of the hypertext model. It is 
the purpose of this report to describe this meta-model within the context of the Trellis model and 
further to suggest that it is applicable to other models of hypertext as well. As such it may serve 
as an appropriate framework for the development of a general hypertext reference model. In this 
report we shall call the "meta-model" the Trellis hypertext reference model, abbreviated as r-model, 
as a reflection of this application. The model of hypertext itself will be called the hypertext model, 
or more simply the model throughout the report. 

The Trellis hypertext reference model is based around a collection of representations of the 
hypertext at different levels of abstraction. Abstractions range from the hypertext as a collection 
of abstractly- defined independent components through more concrete representations in which the 
characteristics of the hypertext's physical display have been established, to the view of the hypertext 
that is projected on a physical display device for the benefit of the person reading the hypertext. 
The representations at a particular level of abstraction depend upon representations at a greater 
level of abstraction, and these dependencies are shown within the r-model. 

A description of the r-model follows in the next section. Section 3 discusses how selected 
components of existing hypertext systems and models fit into (or are omitted from) the r-model. 

'Supported in part by a grant from the National Science Foundation, CCR-8810312. 



-83- 



Abstract Component Level 



Structure 



Abstract 
Contents 



Content-Structure 
Associations 



Abstract 
Buttons 



Button-Structure 

Associations 



Abstract 
Containers 




Abstract Hypertext Level 



Container-Structure 

Associations 




Concrete Hypertext Level 



Concrete 
Windows 




Visible HT 
Segment 



Visible HT 
Segment 



Visible HT 
Segment 



User Display User Display User Display 

Figure 1: The Trellis Hypertext Reference Model (the r-model) 



-84- 



2 The r-model 



The r-model, shown symbolically in Figure 1, is separated into five logical levels. Within each 
level is found one or more representations of part or of all of the hypertext. Speaking quite 
broadly, the levels may be grouped into three overall categories: abstract, concrete, and visible.^ 
The abstract component and abstract hypertext levels define an abstract representation of the 
pieces of the hypertext and of the hypertext itself. These abstractions are transformed into more 
concrete representations of the hypertext in the concrete context and concrete hypertext levels, 
representing first the presentation of the hypertext's content and then the mapping of that content 
into the displayed windows. The resulting concrete windows are then viewed, producing one or 
more displays on one or more physical display devices. In summary, the representations in the 
abstract component level are at the greatest level of abstraction and those in the visible hypertext 
level are at the lowest level. 

Each representation is shown in the figure as a box. A representation is itself an abstract 
concept — a consistent presentation of the hypertext elements of interest. Representations in the 
r-model may depend on the representations at a greater level of abstraction. Such a dependency is 
shown in the figure as an arc between the representations. Because a representation's dependencies 
are on those representations at a greater level of abstraction, and not on those at the same or lower 
levels of abstraction, the abstract and concrete levels in the diagram are further subdivided. It is 
worth emphasizing that a representation may not actually correspond to a separately-identifiable 
"physical" representation of the hypertext; for example, the representation may be expressed as a 
mapping between elements of more abstract representations. 

We will now focus in turn on each of the levels of the r-model. In the following sections, we will 
describe the level, its representations, and discuss the dependencies on representations at higher 
levels. 

2.1 Abstract hypertext 

An abstract hypertext description specifies a hypertext and its components, but does not describe 
the details of how the hypertext is to be presented to its reader. 

2.1.1 Abstract component level 

The organization of the three highest levels reflects a separation of the hypertext into structure, 
content, and context. The structure represents the elements of the hypertext and their relationships. 
The specific content of the hypertext as presented to the system's user reflects the context within 
the structure in which the content appears — in other words, the display of the content is modified 
to reflect its context. 

The representations within the abstract component level present the components that will be 
associated with one-another to form the hypertext. Within the context of this level, the representa- 
tions are independent of each other — such associations will be made at lower levels of abstraction. 
Our abstract view of a hypertext separates out the hypertext's structure from the elements that 
many users perceive as composing the hypertext. In other words, the structure, perhaps a directed 
graph, is separated from the collection of contents that are to be displayed to the reader and the 

^The choice of these levels of representation parallels and expands Shaw's model of printed documents [ShaSO] 
which identifies abstract, concrete, and viewing mappings for the document. 



-85- 



collection of "buttons" that will be selected by the reader when moving from location to location 
in the hypertext. Additionally, it may be the case that the view of the hypertext presented to the 
reader combines together independent content elements into an integrated whole. The presence (or 
absence) of such composition is also represented abstractly at this level. We will now consider each 
of the representations in turn. 

One natural representation for the structure of the hypertext is as a network. In our own 
work, we use a Petri net structure, which provides automaton semantics as well as the network rep- 
resentation. However other graph-based structures are appropriate as well — for example automata 
such as deterministic finite automata or data structures such as directed graphs, trees, or lattices. 
The structure of the hypertext need not be limited to networks; indeed, it may be desirable to use 
representations that are not graph-based in form; for example constraint-based descriptions. Note 
that even in graph-based representations, there is no requirement that the elements of the structure 
be fully-connected. The necessary characteristics of the structure representation is that it provides 
the "placeholders" that will be associated with the hypertext's content and that it describes the 
relationships that exist among these placeholders. 

The abstract content is arbitrary in form. It may, for example, include textual, graphical, 
animated, or perhaps even audio and video material. The content may be specified directly or 
may be the result of a computation. While it does not contain links, it may incorporate markers 
that define a collection of potential locations for the mappings of links and their presentations that 
occur in lower levels of the r-model. The content may be described in a form that is independent 
of the eventual characteristics of its display, or indeed it may be described in a form that is highly 
dependent on the eventual display. Because of the flexibility of the mapping from content to 
structure in the next level, however, a display-independent representation seems most appropriate. 

The structure representation identifies the relationships among content elements but does not 
indicate how those relationships will be shown for selection by the hypertext's reader. The abstract 
buttons are abstractions of the ways in which the relationship can be displayed. Abstract buttons 
may themselves have content and an associated type. The content is provided to specify what will 
be shown when the button is displayed. The type is needed to specify how the button will be 
displayed and other characteristics of its behavior on display and selection. As with the content of 
the abstract content, the content of the abstract button is variable in form — in implementation it 
actually may be computed or it may be statically defined. 

The final component in this level, the abstract containers, differs from the others in that it 
is an abstraction of how the pieces of the hypertext will be combined when shown to the reader 
{how it will be aggregated and combined for display), and not of what is in the hypertext. For 
example, if several content elements are displayable, one possible presentation would be to show 
each element separately while another would be to combine the separate elements into a composite, 
which would be presented to the reader as a unit. In the first case, one could say that a separate 
container had been associated with each separate content element, while in the second case, one 
container would hold all content elements. Such characteristics are abstracted at this level by the 
abstract containers. 

2.1.2 Abstract hypertext level 

The elements of the abstract component level are not connected together, as will be necessary to 
form a hypertext. This association is performed in the abstract hypertext level. The abstract 



hypertext level does not, however, describe how these associations will be presented within the 
display of the hypertext. This is left to the concrete context level. 

The content-structure associations map together elements of the structure and elements of 
the abstract content. In a graph-based structure, one natural association is to map the content ele- 
ments to the nodes of the graph. No restriction is expressed in the r-model on the kinds of mappings 
that are permissible — for example it may be useful to map a single content element to multiple 
locations in the structure, or conversely to map multiple content elements to a single location. In 
our own work, we have found the ability to map a single content element to multiple locations 
to be particularly useful. We have also found it useful to completely substitute a new collection 
of abstract contents and of content-structure associations while retaining the same structure — for 
example for related hypertext versions, where one may perhaps be a translation of the other. 

The button-structure associations map the structure's relationship and abstract buttons. 
A natural association in a graph-based structure is to map the abstract buttons to arcs in the 
graph. In our Trellis hypertext model, based on Petri nets, the mapping is between the class of 
node called a transition and the abstract buttons (i.e., there is no mapping of arcs in this particular 
graph structure). Again we emphasize that there are no limitations expressed on the form of the 
mapping, although we have found a one-to-one mapping to be the most useful. 

Finally, the container-structure associations describe the association of the structure, or 
of portions of the structure, to one or more abstract containers. One use of this association is to 
permit grouping of elements of the structure, which might in turn be displayed to the reader in a 
single physical window. Different kinds of composite displays would be represented as associations 
with different types of abstract containers. In general, the container-structure associations allow 
the partitioning of the subsequent display of the hypertext into one or more possibly overlapping 
pieces. 

2.2 Concrete hypertext 

Assume that a hypertext is presented to its reader or readers in one or more windows on one or 
more physical display devices.'^ A concrete hypertext description specifies what the contents of 
each of these windows will look like but does not tie down how the windows are to be arranged 
on the display. For example, one particular window may be shown on several separate displays. 
Furthermore, the characteristics of the displays may be different; in this case the subsequent viewing 
description will also indicate how the different visible effects specified by the concrete description 
are to be rendered on the displays. 

2.2.1 Concrete context level 

The previously-described levels have defined an abstract hypertext in which the content and the 
buttons have been associated with the structure. However, the abstract hypertext description does 
not indicate how links are to be presented in the display of the content. Such considerations of the 
mapping from the hypertext's abstract representation to its physical representation are addressed 
in the concrete context level. 

The concrete content presents a physically-oriented description of the hypertext. This mapping 
must a,ddress the following points: 

^Here a window contains a concrete view of the hypertext (or portion of the hypertext) to be presented to the 
reader. 



-87- 



How is the abstract content to be formatted to fit within the display region? 



• How are the buttons to be displayed? Will the display of the button modify the display of 
the content or will the buttons and content be displayed independently? For example, in 
our initial Trellis prototype (ctTrellis), we have provided externally represented buttons. In 
our subsequent prototype (xTrellis), we have also developed means for specifying that the 
button is to be represented as a highlighted string within textual context [FS89a]. Note that 
button displays are not necessarily static; in some cases the display of the button depends on 
computed material (which itself may depend on the structural relationships in the hypertext). 
The button represents the source of a link in the hypertext.^ 

• Is the target of a link associated with a content element as a whole, or is it associated with 
a particular location within that content? Does the display of the target affect the display of 
the content? 

The mappings on this level do not rely directly on the structure (abstract component level) because 
the structural relationships have been "encoded" into the representations of the abstract hypertext 
level. 

2.2.2 Concrete hypertext level 

The concrete context level has defined a set of concrete content elements in which a concrete 
representation of the content has been merged with concrete representations of the buttons. The 
concrete hypertext level maps those concrete representations into a set of windows for display. The 
mapping, which produces the concrete windows representation, also requires that link-based 
interrelationships among the windows be determined. For example, the process of following a link 
can result in several different display mappings: the display of the target of the link could replace 
the display of the source, could be shown in addition to the source, or could modify the display of 
the source, with both being shown in the same window. 

When the concrete windows representation has been formed, the presentation of the hypertext 
has been determined but the details of how and where the windows are to be displayed has not. For 
example, multiple windows may be shown to a single reader on a display or a particular window 
may be shown to several reader simultaneously on separate displays. Indeed, a particular reader 
may have several physical displays at his disposal, and different displays may have equivalent but 
different means for achieving particular visual effects. Such considerations are addressed in the 
next level. 

2.3 Displayed (visible) hypertext 

The details of the mapping from the concrete hypertext to the visible presentation of the hypertext 
for the reader are specified here.^ However, user interface details, such as the positioning and sizing 
of windows, are orthogonal to the r-model, as discussed later in this report. 

■^See also the comparison with anchors that follows in section 3.1.2. 

• "Visible presentation" is a simplification, since the presentation is not limited to being visible. For example, it 
might be audible, etc. 



-88- 



2.3.1 Visible hypei'text level 

An assuinption in the r-model is that the underlying hypertext is to be permitted to be used in a 
distributed environment. The visible hypertext level reflects this assumption. Each visible HT 
segment is associated with a separate user and display. Each segment presents one or more of 
the active concrete windows to its viewer. The model does not prevent the display of a particular 
concrete window in more than one segment. Whether (and how) the effects of user interactions to 
one display may affect what is shown on other user displays is a property of the hypertext model, 
and not of the r-model. 

3 Issues in application of the r-model 

We now turn our attention to three aspects of the r-model, which we shall consider in detail. In 
Section 3.1, we discuss some important components of hypertext systems and how they fit into the 
r-model. In Section 3.2, we turn our attention to central issues in implementation of a hypertext 
system that are orthogonal to our model- centered r-model. Finally, in Section 3.3, we discuss the 
intersection of our r-model with already-existing defined and defacto standards. 

3.1 Further discussion of elements of the r-model 

A number of structures and components have been identified for hypertexts.^ Here, we present 
some of these hypertext elements and describe their categorization within our reference model. 

3.1.1 Hypertext model structures 

We emphasize that the hypertext's abstract structure is arbitrary in form within the reference 
model. It may be graph-based, describing only object interrelationships, or it may also have 
automaton semantics. It need not be homogeneous in form; heterogeneous structures may be 
appropriate for some applications. It need not be static in form but may be dynamic. Indeed, it 
need not be explicitly computed or represented. What is required, however, is that it be possible 
to intuit where it is possible to include content in the hypertext and also the relationships between 
elements of the content. 

3.1.2 Anchors 

In some other models of hypertext, anchors have been identified as separatable component of 
a hypertext.^ The anchor represents the terminating point or points of a link. In one general 
form, anchors may be associated with both the source and the target of a one-directional link in 
a hypertext. They present the relationship between the identified portion of the source and the 
identified portion of the target. In other implementations, anchors are only associated with source, 
with the target being the node as a whole. In our Trellis implementations, anchors may or may 
not be associated with the source — when no anchor is associated with a source then the link is 
represented by a (graphical) button in a separately displayed palette. 

^See [LSK88], for example, for definitions of related terminology. 
®See, for example, the Dexter reference model [HS90]. 



-89- 



Within the r-model, the display of anchors in source and target is specified in the mapping that 
defines the concrete content (concrete context level). Both the form of the display and also its 
position are described here. Issues involving positioning of the target content's display when a link 
is followed are addressed in the definition of the concrete windows (concrete hypertext level). 

3.1.3 Different flavors of links 

A hypertext implementation may contain several different kinds of links, each with a different 
implemented action on selection. The distinction between the different types of link is reflected in 
the r-model by a difference between the types of their corresponding abstract buttons. 

The display of the source or target of a link may be static or may be computed. Such displays 
are described within the mapping that produces the concrete content representation. 

In some circumstances selection of a link may cause an apparent change to the displayed content, 
for example, insertion of the target's content into place in the source. When the content actually 
changes in form, this is a matter of interest in the concrete content. However, when the content is 
actually unchanged in form, as is the case when the target material is inserted, this can be described 
through the display mapping that produces the concrete windows representation. 

3.1.4 Dynamic content 

Abstract content may be statically defined or it maj^ be computed. It is useful to distinguish 
separate categories of computed content from one another. One such categorization distinguishes 

• Computed content: executor of an algorithm that produces a subsequently static display 

• Dynamic content: Dynamic execution of an algorithm: start on node entry, terminate on 
node exit 

• Filtered computation: Continuously-executing filter 
3.2 Orthogonal considerations 

The r-model is centered around organizing and categorizing the parts of a model of hypertext. 
Consequently, there are elements of an implementation, as well as elements of some hypertext 
models, that are not included in the r-model. These will be presented in this section of the report. 

3.2.1 Hypertext browsing semantics 

We have previously defined a hypertext system's browsing semantics [SF89a] as the dynamic prop- 
erties of a reader's experience when browsing a document; in other words, as the manner in which 
the information within the hypertext is to be visited and presented. In most cases, browsing seman- 
tics are specified by the code that implements the hypertext system. However, it is also possible 
to develop a hypertext model with variable browsing semantics; for example our Trellis hypertext 
model permits specification of the hypertext's browsing semantics [FS89b].^ Although specifiable 

'^The behaviors associated with different link types are reflected by their browsing semantics. Consequently, 
variable browsing semantics are the implementation mechanism for user-defined link types, as well as other browsing 
behaviors. 



-90- 



browsing semantics are in some hypertext models, they are not in all, and so we have decided not 
to include them directly in the r-model. 

Similarly, we have not included the hypertext's dynamic behavior in the r-model. By dynamic 
behavior, we mean those cases in which a hypertext system traverses the structure without inter- 
vention from the reader [SF89b]. Dynamic behavior is distinct from dynamic content, however. As 
noted above, dynamic content is described within the model. 

3.2.2 Characteristics of the content 

Some hypertext systems may favor an organization in which each piece of content is treated as 
a small card-sized unit while others favor organizations in which the content is viewed as a long 
continuous scroll. Such considerations are outside of the scope of the r-model. 

3.2.3 Physical-level descriptions and interchange descriptions 

If the structure of the implemented hypertext system closely parallels that of the r-model, it will 
certainly be necessary to define a storage format for those representations that are specified directly 
as well as a description of the mappings that produce the others. However, the specific design of 
such storage formats is outside of the scope of the r-model, as is the equally-important design of 
formats designed to permit interchange between hypertext systems and installations. 

3.2.4 User interfaces 

Certainly to the reader of a hypertext, the most visible component of the system is its user interface. 
However, the user interface is also an element of the system not discussed in the r-model. We note 
that it is possible to associate many different styles of user interface with the same underlying 
hypertext model. 

3.3 Intersection with existing standards 

There are two points of intersection between the r-model and existing standards. The first, in the 
abstract component level, are the abstractions used to define the abstract content. An appropriate 
standard to consider for text, for example, would be SGML [IS086]. Similar utility could be made 
of standards to define graphical material as well as other content objects. It may be necessary, 
however, to augment these standard representations with additional information describing the 
potential interactions defined by the concrete-structure and button-structure associations, and as 
reflected in the concrete content. 

The other point of intersection with proposed standards is in the visible hypertext level. Each 
visible HT segment and user display may be based around a protocol such as that of the X- windows 
system [SG86]. Other defacto interface standards such as SunTools, OpenLook, Viewpoint, Motif, 
and NextStep are also applicable at this point. 

4 Discussion and conclusions 

We have described a meta- model of hypertext, which we call the r-model, that helps to organize the 
portions of a hypertext model. It is possible that the hypertext model's design will also correspond 



-91- 



to the divisions established in the r-model, but it is equally permissible that the relationships 
be less-clearly drawn in the hypertext model. Furthermore, the implementation of the hypertext 
system may also correspond directly to the model or again distinct model concepts may be merged 
in implementation. 

In our own work in developing the Trellis hypertext model and prototype implementations, we 
have tended to reflect the divisions of the r-model strongly in our hypertext model and also to 
carry these divisions on into our implementation. In essence, our implementation is based on a 
collection of abstract data types, where the data types correspond to the representations in the 
r-model. A natural consequence of this retention of separation has been that it is easy to extend 
the environment in which the implementation resides — for example to consider designs that permit 
multiple readers to be active in the hypertext at the same time that a writer is modifying it. 
Moreover the retention of separation between structure, content, and context permits flexible reuse 
of the hypertext's structure and of the content of the hypertext. 

While we believe that direct application of the r-model has benefits in guiding the implemen- 
tation of a hypertext system, we also believe that a greater understanding of a hypertext model 
can be gained by casting it into the form of the r-model. It is this increased understanding that we 
believe is of primary importance outside of the context of our own development. 

Acknowledgments 

< We would like to thank the Hypertext Standardization Workshop program committee, particularly 
Judi Moline, for comments that helped us to clarify the points of this report. We also would like to 
thank the participants in the Workshop's Hypertext Reference Model working group, particularly 
John Leggett, for discussions that helped identify the similarities and differences between this model 
and the others that have been proposed. 

References 

[FS89a] Richard Furuta and P. David Stotts. Separating hypertext content from structure in 
Trellis. In Proceedings of Hypertext 2, June 1989. University of York, June 29th and 30th, 
1989. 

[FS89b] Richard Furuta and P. David Stotts. Programmable browsing semantics in Trellis. In 
Hypertext '89 Proceedings, pages 27-42. ACM, New York, November 1989. 

[HS90] Frank Halasz and Mayer Schwartz. The Dexter hypertext reference model, January 1990. 
These proceedings. 

[IS086] ISO. Text and Office Systems — Standard Generalized Markup Language, October 1986. 
Document Number: ISO 8879-1986(E). 

[LSK88] John Leggett, John L. Schnase, and Charles J. Kacmar. Working definitions of hyper- 
text. Technical Report TAMU 88-020, Department of Computer Science, Texas A&M 
University, October 1988. 

[SF89a] P. David Stotts and Richard Furuta. Petri-net-based hypertext: Document structure with 
browsing semantics. ACM Transactions on Information Systems, 7(l):3-29, January 1989. 



-92- 



[SF89b] P. David Stotts and Richard Furuta. Temporal hyperprogramming. Technical Report 
CS-TR-2349 and UMIACS-TR-89-113, University of Maryland Department of Computer 
Science and Institute for Advanced Computer Studies, November 1989. 

[SG86] Robert W. Scheifier and Jim Gettys. The X Window system. ACM Transactions on 
Graphics, 5(2):79-109, April 1986. 

[Sha80] Alan C. Shaw. A model for document preparation systems. Technical Report 80-04-02, 
University of Washington, Department of Computer Science, Seattle, WA, April 1980. 



-93- 



The Dexter Hypertext Reference Model* 



Frank Halasz 



Mayer Schwartz 



Xerox PARC 



Tektronix Labs 



3333 Coyote Hill Rd. 
Palo Alto, CA 94304 
halasz@xerox.com 



P.O. Box 500, MS 50-662 
Beaverton, OR 97077 
mayers@tekchips.labs.tek.com 



December 7, 1989 

Submttied io the NIST Hypertexi Standardizaiion Workshop, 
Gaiihersburg, MD, January 16-18, 1990 



Abstract 



This paper presents the Dexter hypertext reference model. The 
Dexter model is an attempt to capture, both formally and informally, 
the important abstractions found in a wide range of existing and future 
hypertext systems. The goal of the model is to provide a principled 
basis for comparing systems as well as for developing interchange and 
interoperability standards. The model is divided into three layers. 
The storage layer describes the network of nodes and links that is the 
essence of hypertext. The runtime layer describes mechanisms support- 
ing the user's interaction with the hypertext. The within-component 
layer covers the content and structures within hypertext nodes. The 
focus of the model is on the storage layer as well as on the mechanisms 
of anchoring and presentation specification that form the interfaces 
between the storage layer and the within-component and runtime lay- 
ers, respectively. The model is formalized using Z [19], a specification 
language based on set theory. The paper briefly discusses the issues 
involved in comparing the characteristics of existing systems against 
the model. 



* AcknowledgeiTient: The model described in this paper grew out a series of workshops 
on hypertext. The following people attended these workshops and were instrumental in 
the development of the model; Rob Akscyn, Doug Engelbart, Steve Feiner. Frank Ha- 
lasz, John Leggett, Don McCracken, Norm Meyrowilz, Tim Oren, Amy Pearl, Catherine 
Plaisant, Mayer Schwartz, Randy Trigg, Jan Walker, and Bill Wieland. The workshops 
were organized by Jan Walker and John Leggett. 



-95- 



What do hypertext^ystems such as NoteCards [10], Neptune [4], KMS 
[1], Intermedia [23] and Augment [6] have in common? How do they differ? 
In what way do these systems differ from related classes of systems such 
as multimedia database systems. At a very abstract level, each of these 
hypertext systems provides its users with the ability to create, manipulate, 
and/or examine a network of information-containing nodes interconnected 
by relational links. Yet these systems differ markedly in the specific data 
models aiid sets of functionality that they provide to their users. Augment, 
Intermedia, NoteCards, and Neptune, for example, all provide their users 
with a universe of arbitrary-length documents. KMS and HyperCard, in 
contrast, are built around a model of a fixed-size canvas onto which items 
such as text and graphics can be placed. Given these two radically different 
designs, is there anything common between these systems in their notions 
of hypertext nodes? 

In an attempt to provide a principled basis for answering these ques- 
tions, this paper presents the Dexter hypertext reference model. The model 
provides a standard hypertext terminology coupled with a formal model of 
the important abstractions commonly found in a wide range of hypertext 
systems Thus, the Dexter model serves as a standard against which to com- 
pare and contrast the characteristics and functionality of various hypertext 
(and non-hypertext) systems. The Dexter model also serves as a principled 
basis on which to develop standards for interoperability and interchange 
among hypertext systems. 

The Dexter reference model described in this paper was initiated as the 
result of two small workshops on hypertext. The first workshop was held in 
October, 1988 at the Dexter Inn in New Hampshire. Hence the name of the 
model. The workshops had representatives from many of the major existing 
hypertext systems^. A large part of the discussion at these workshops was 
the elicitation of the abstractions common to the major hypertext systems. 
The Dexter model is an attempt to capture, fill-out, and formalize the results 
of these discussions. 

'The term.s hypertext and hypiermedia are often differentiated, with hypertext referring 
to text-only systems and hypermedia refering to systems that support multiple media. 
This distinction is not made in the present paper; the term hyf>ertext is used generically 
to refer to both text-only and multimedia systems. 

^Participants in the two workshops are listed in the acknowledgements on the first page 
of this paper. 

Among the systems that were discussed at the workshops were: Augment, Concor- 
dia/Document Examiner, IGD, FRESS, Intermedia, HyperCard, Hyperties, KMS/ZOG, 
Neptune/HAM, NoteCards, the Sun Link Service, and Textnet. 



-96- 



Another important focus of the workshops was an attempt to find a 
common terminology for the hypertext field. This turned out to be an 
extremely difficult task, especially so in the absence of an understanding of 
the common (and differing) abstractions among the various systems. The 
term "node" turned out to be especially difficult given the extreme variation 
in the use of the term across the various systems. By providing a well- 
defined set of named abstractions, the Dexter model provides a solution to 
the hypertext terminology problem. It does so, however, at some cost. In 
order to avoid confusion, the model does not use contentious terms such as 
"node", prefering neutral terms such as "component" for the abstraction in 
the model. 

In the present paper, the Dexter model is formulated in Z [19], a formal 
specification language based on typed set theory. The use of Z provides a 
rigorous basis for defining the necessary abstractions and for discussing their 
use and interrelationships. Although an understanding of the Z language 
is a prerequisite for fully understanding the details of the Dexter model as 
described in this paper, the paper attempts to provide a complete description 
of the model in the prose accompanying the formal specification. Readers 
unfamiliar with Z should be able to gain a full, if not precisely detailed, 
understanding of the model. 

This paper also refers in passing to architectural concepts found in 
a number of existing hypertext systems including Augment [6], Concor- 
dia/Document Examiner [22], HyperCard [8], Hyperties [18], IGD [7], In- 
termedia [23], KMS [1], Neptune/HAM [4], NoteCards [10], the Sun Link 
Service [17], and Textnet [20]. The reader is assumed to be familiar with 
the general characteristics and functionality of these systems. Appropriate 
background material on these systems can be found in Conklin [3] and in 
the proceedings of the Hypertext 87 [11] and Hypertext 89 [12] conferences. 

This paper is divided in 4 main sections. The first section provides a 
brief discursive overview of the entire model. The second section describes 
the storage layer of the model, both formally and informally. The third 
section describes the runtime layer of the model in a similar manner. The 
final section discusses issues involved in comparing existing systems against 
the model. 



-97- 



Focus of the 
Dexter Model 



Figure 1: Layers of the Dexter model. 

1 An Overview of the Model 

The Dexter model divides a hypertext system into three layers, the run- 
time layer, the storage layer and the within-component layer, as illustrated 
in Figure 1. The main focus of the model is on the storage layer, which 
models the basic node/link network structure that is the essence of hyper- 
text. The storage layer describes a 'database' that composed of a hierar- 
chy of data- containing "components" which are interconnected by relational 
"links". Components correspond to what is typically thought of as nodes in 
a hypertext network: cards in NoteCards and HyperCard, frames in KMS, 
documents in Augment and Intermedia, or articles in Hyperties. Compo- 
nents contain the chunks of text, graphics, images, animations, etc. that 
form the basic content in the hypertext network. 

The storage layer focuses on the mechanisms by which the components 
and links are "glued together" to form hypertext networks. The components 
are treated in this layer as generic containers of data. No attempt is made 
to model any structure within the container. Thus, the storage layer makes 
no differentiation between text components and graphics components. Nor 
does it provide any mechanisms for dealing with the W2ll-defined structure 
inherent within a structured document (e.g., an ODA document) compo- 



Runtime Layer 

Presentation of the tiypertext; 
user interaction; dynamics 



Storage Layer 

a 'database' containing a 
network of nodes and links 



Within Component Layer 

the content/structure inside 
the nodes 



-98- 



nent. 

In contrast, the within-component layer of the model is specifically con- 
cerned with the contents and structure within the components of the hyper- 
text network. This layer is purposefully not elaborated within the Dexter 
model. The range of possible content/structure that can be included in a 
component is open-ended. Text, graphics, animations, simulations, images, 
and many more types of data have been used as components in existing 
hypertext systems. It would be folly to attempt a generic model covering 
all of these data types. Instead, the Dexter model treats within-component 
structure as being outside of the hypertext model per se. It is assumed 
that other reference models designed specifically to model the structure of 
particular applications, documents, or data types (ODA, IGES, etc) will be 
used in conjunction with the Dexter model to capture the entirety of the 
hypertext, including the with-component content and structure. 

An extremely critical piece of the Dexter model, however, is the inter- 
face between the hypertext network and the within-component content and 
structure. The hypertext system requires a mechanism for addressing (refer- 
ing to) locations or items within the content of an individual component. In 
the Dexter model, this mechanism is know as anchoring. The anchoring 
mechanism is necessary, for example, to support span-to-span links such 
as are found in Intermedia. In Intermedia, the components are complete 
structured documents. Links are possible not only between documents, but 
between spans of characters within one document and spans of characters 
within another document. Anchors are a mechanism that provides this 
functionality while maintaining a clean separation between the storage and 
within-component layers. 

The storage and within-component layers treat hypertext as an essen- 
tially passive data structure. Hypertext systems, however, go far beyond 
this in the sense that they provide tools for the user to access, view, and 
manipulate the network structure. This functionality is captured by the 
runtime layer of the model. As in the case of within-component structure, 
the range of possible tcxjls for accessing, viewing, and manipulating a hy- 
pertext networks is far too broad and too diverse to allow a simple, generic 
model. Hence the Dexter model provides only a bare-bones model of the 
mechanism for presenting a hypertext to the user for viewing and editing. 
This presentation mechanism captures the essentials of the dynamic, inter- 
actional aspects of hypertext systems, but it does not attempt to cover the 
details of user interaction with the hypertext. 

As in the case of anchoring, a critical aspect of the Dexter model is the 



-99- 



"View as 




Presentation spedfications 
on link access path 



Figure 2: Dlustration of the need for presentation specifications on the access 
path (i.e., Links) as well as on the components themselves. 

interface between the storage layer and the runtime layer. In the Dexter 
model this is axrcomplished using the notion of presentation specifications. 
Presentation specifications axe a mechanism by which information about 
how a component/network is to be presented to the user can be encoded 
into the hypertext network at the storage layer. Thus, the way in which a 
component is presented to the user can be a function not only of the specific 
hypertext tool that is doing the presentation (i.e., the specific runtime layer), 
but can also be a property of the component itself and/or of the access path 
(link) taken to that component. 

Figure 2 illustrates the importance of the presentation specifications 
mechanism. In this figure, there is an animation component taken from 
a computer-based training hypertext. This animation component can be 
accessed from two other components, a "teacher" component and a "stu- 
dent" component. When following the link from the student component, 
the animation should be brought up as a running animation. In contast, 
when coming from the teacher component, the animation should be brought 
up in editing mode ready to be altered. In order to separate these two cases, 
the runtime layer needs to access presentation information encoded into the 
Links in the network. Presentation specifications are a generic way of doing 
just this. Like anchoring, it is an interface that allows the storage layer to 
communicate in generic way with the runtime layer without violating the 
separation between the two layers. 

Figure 3 attempts to give a flavor of the various layers of the Dexter 
model as they are embedded within an typical hypertext system. The fig- 



-100- 




Runtime Layer Storage Layer Within-Component 

Layer 

Figure 3: A depiction of the three layers of the Dexter model as embedded 
in an actual hypertext system. 

ure depicts a 3 node/1 link hypertext network. The storage layer contains 
four entities: the three components (i.e., nodes) and the link. The actual 
contents (text and graphics) for the components are located to the right of 
the storage layer in the within-components layer. In the runtime layer, the 
single graphics component is being presented to the user. The link emanat- 
ing from this node is marked by an arrowhead located near the bottom of 
the node's window on the computer screen. 

2 Simple Storage Layer Model 
2.1 An Overview of the Storage Layer 

The storage layer describes the structure of a hypertext as a finite set of 
components together with two functions, a resolver function and an accessor 
function. The accessor and resolver functions are jointly responsible for 
"retrieving" components, i.e., mapping specifications of components into 
the components themselves. 

The fundamental entity .and basic unit addressability in the storage layer 
is the component. A component is either an atom, a link, or a composite 



-101- 



entity made up from other components. Atomic components are primitive 
in the (storage layer of the) model. Their substructure is the concern of the 
within-components layer. Atomic components are what is typically thought 
of a "node" in a hypertext system, e.g., a card in NoteCaxds, a frame in 
KMS, a document in Intermedia, a statement in Augment. Links are entities 
that represent relations between other components. They are basically a 
sequence of 2 or more "endpoint specifications" each of which refers to (a 
part of) a component in the hypertext. The structure of links will be detailed 
below. Composite components are constructed out of other components. 
The composite component hierarchy created when one composite component 
contains another composite is restricted to be a direct- acyclic graph (DAG), 
i.e., no composite may contain itself either directly or indirectly. Composite 
components are relative rare in the current generation of hypertext systems. 
One exception is the Augment system where a document is a tree-structured 
composition of atomic components called statements. 

Every component has a globally unique identity which is captured by 
its unique identifier (UID). UIDs are primitive in the model, but they are 
assumed to be uniquely assigned to components across the entire universe of 
discourse (not just within the context of a single hypertext). The accessor 
function of the hypertext is responsible for "accessing" a component given 
its UID, i.e., for mapping a UID into the component "assigned" that UID. 

UIDs provide a guaranteed mechanism for addressing any component 
in a hypertext. But the use of UIDs as a basic addressing mechanism in 
hypertext may be too restrictive. For example, it is possible in the Augment 
system to create a link to "the statement containing the word 'pollywog'". 
The statement specified by this link may not exist or it may change over 
time as documents are edited. Therefore, the link cannot rely on a specific 
statement UID to address the target statement. Rather, when the link is 
followed, the specification must be "resolved" to a UID (if possible), which 
then can be used to access the correct component. 

This kind of indirect addressing is supported in the storage layer using 
component specifications together with the resolver function. The resolver 
function is responsible for "resolving" a component specification into a UID, 
which can then be fed to the accessor function to retrieve the specified com- 
ponent. Note, however, that the resolver function is only a partial function. 
A given specification may not be resolvable into a UID, i.e., the component 
being specified may not exist. However, it is the case that for every com- 
ponent there is at least one specification that will resolve to the UID for 
that component. In particular, the UID itself may be used as a specifier, in 



-102- 



which case the resolver function is the identity function. 

Implementing span-to-span links (e.g., in Intermedia) requires more than 
simply specifying entire components. Span-to-span linking depends on a 
mechanism for specifying substructure within components. But in order 
to preserve the boundary between the hypertext network per se and the 
content/structure within the components, this mechanism cannot depend 
in any way on knowledge about the interna! structure of (atomic) compo- 
nents. In the Dexter model, this is accomplished by an indirect addressing 
entity called an anchor. An anchor has two parts: an anchor id and an 
anchor value. The anchor vaJue is an arbitrary value that specifies some lo- 
cation, region, item, or substructure within a component. This anchor vaJue 
is interpretable only by the applications responsible for handling the con- 
tent/structure of the component. It is primitive and unrestricted from the 
viewpoint of the storage layer. The anchor id is an identifier which uniquely 
identifies its anchor within the scope of its component. Anchors can there- 
fore be uniquely identified across the whole universe by a component UID, 
anchor id pair. 

The two part composition of anchor is designed to provide a fixed point 
of reference for use by the storage layer, the anchor id, combined with a 
variable field for use by the within-component layer, the anchor value. As 
a component changes over time (e.g., when it is edited within the runtime 
layer), the within-component application will change the anchor value to 
reflect changes to the internal structure of the component or to reflect within 
component movement of the point, region, or items to which the anchor 
is conceptually attached. The anchor is, however, will remain constant, 
providing a fixed referent that can be used to specify a given structure 
within a component. 

The mechanism of the anchor id can be combined with the component 
specification mechanism to provide a v/ay of specifying the endpoints of 
a link. In the model, this is captured by an entity called a specifier which 
consists of a component specification, an anchor id, and two additional fields: 
a direction and a presentation specification. A specifier specifies a component 
and an anchor 'point' within a component that can serve as the endpoint 
of a link. The direction encodes whether the specified endpoint is to be 
considered a source of a link, a destination of a link, both a source and a 
destination, or neither a source nor a destination. (These are encoded by 
direction values of FROM, TO, BIDIRECT, and NONE, respectively.) The 
present specification is a primitive value that forms part of the interface 
between the storage layer and the runtime layer. The nature and use of 



-103- 



C<»poslt« f4112 



M.txibatos 
rr«MOt«tl«>_Sp«s 9BSSai 



ID 
t1 



MciihtK nods 



and 00 on and on 



'resolves to' 




9p»al flats 
C«»Fceaiat_B|poei #4112 
Ascaies_IS f1 




'resoives to'j, 



Figure 4: A depiction of overall organization of the storage layer including 
specifiers, links, and anchors. 



present specifications will be discussed in conjunction with the runtime layer 
below. 

Returning to the issue of link components, it is now possible to describe 
their structure a bit more precisely. Ln particular, a link is simply a sequence 
of 2 or more specifiers. Note that this provides for links of arbitrary arity, 
despite the fact that binary links are standard in existing hypertext systems. 
Directional links, cdso standard in existing systems, are handled using the 
direction field in the specifier. 

Figure 4 depicts the overall organization of the storage layer including 
specifiers, links, and anchors. The figure depicts 5 components including 3 
atomic components, 1 composite component (that constructed from two of 
the atomic components plus some text), and 1 link component that repre- 
sents a connection from the anchor (i.e., span) within an atomic component 
(#3346) to the anchor (span) in the composite component (#4112). 

In the foregoing discussion, components were described as being either 
a atom, a link, or a composition of other components. In actuality, this 
describes what the model calls a base component. In contrast, components 
in the model are complex entities that contain a base component together 
with some associated component information. The component information 



-104- 



describes the properties of the component other than its 'content'. Specifi- 
cally, the component information contains a sequence of anchors that index 
into the component, a present specification that contains information for the 
runtime layer about how the component should be presented to the user, 
and a set of arbitrary attribute/value pairs. The attribute/value pairs can 
be used to attach any arbitrary property (and its vaJue) to a component. For 
example, keywords can be attached to a component using mutiple 'keyword' 
attributes. Similarly, a component type system can be implemented in the 
model by adding to each component a 'type' attribute with an appropriate 
type specification as its value. 

In addition to a data model, the storage layer defines a small set of op- 
erations that can be used to access and/or modify a hypertext. All of these 
operations are defined in such a way a^ to maintain the invariants of the 
hypertext, e.g., the fact that the composition hierarchy of components/sub- 
components is acyclic. The operations defined in the model include adding 
a component (atomic, link or composite) to a hypertext, deleting a compo- 
nent from 'he hypertext, and modifying the contents or ancilliary informa- 
tion (e.g., anchors or attributes) of a component. There are also operatons 
for retrieving a component given its UID or any specifier that can be re- 
solved to its UID. Finally, there is one operation needed for determining the 
interconnectivity of the network structure. This operation, linksToAnchor, 
returns the set of links that refer to an anchor when given the anchor and 
its containing component. 

2.2 Formalization of the Storage Layer 

As described above, we envision a hypertext system consisting of a set of 
components, each of which has a UID from the given set UID. 

[UID] 

Retrieving a component involves finding its UID and then using that 
UID to get hold of the actual component; this is accomplished by means 
of an accessor function which returns a component given its UID. UIDs are 
normally not meant to be visible to clients of a hypertext system. Given 
a component specification, it may be possible to find the UID to which 
the component specification refers, by means of a resolver function. Com- 
ponent specifications arise from the given set COMPONENT-SPEC. We 
also have a description for the visual presentation (present spec) of a com- 
ponent, which as part of a component is used in the run-time layer but 



-105- 



not in the storage layer; these visual descriptions come from the given set 
PRESENT^SPEC. 

[COMPONENT^PEC, PRESENT JSPEC] 

Links are an important kind of component and are supported in every 
hypertext system. Direction «ility is sometimes important for links, while at 
other times it immaterial. We introduce DIRECTION as a free type to 
model respectively the end of a link as a source, as a destination, as both a 
source and destination, or as neither. 

DIRECTION ::= FROM \ TO \ BYDIRECT \ NONE 

The schema type SPECIFIER essentially takes the form of the descrip- 
tion of one end of a "link." This description is sometimes sufficient to 
determine the UID of the component at one end of a link. As described in 
the overview, anchoring plays an important part in the model. Anchors are 
identified by means of a unique (to a component) anchor id from the given set 
ANCHOR-ID. Anchor values come from the given set ANCHOR-VALUE. 
Anchors are then just pairs of anchor id and associated anchor value. 

[ANCHOR-ID , A NCHOR- VA L UE] 

ANCHOR == ANCHOR-ID x ANCHOR-VALUE 

A value of type SPECIFIER describes a single end of a link. We include 
the variable presentSpec in the SPECIFIER schema so we can model differ- 
ent ways of visually showing links as we follow them (based on the specifier 
used), as illustrated in the example shown in Figure 2. 

SPECIFIER 

componentSpec : COMPONENT-SPEC 
anchorSpec : ANCHOR-ID 
presentSpec : PRESENTSPEC 
direction : DIRECTION 



Links must include at least two specifiers. What appear to be one-way 
links, such as HyperCard buttons, can be modeled as two-way links with the 
button end having a DIRECTION with value NONE and the other end 
having a DIRECTION with value TO. The two specifiers link constraint 
simplifies the hypertext model. On the other hand there is no reason not 



-106- 



to have multi-way links, and so the model accomodates them. In the most 
general model, duplicate specifiers are allowed. The only constraint is that 
at least one specifier have a direction of TO. 

LINK 

specifiers : seq SPECIFIER 

specifiers > 2 
3 5 : ran specifiers • s. direction = TO 



A base component (a generalization of the traditional "node" or "link") 
of a hypertext can either be 

• an atomic element which is modeled by the given type ATOM, 

[ATOM] 

models a "node" of a typical hypertext system but with the internal 
detail omitted. 

• a link which is modeled by the LINK schema given above, or 

• a composite which can be described recursively as a sequence of base 
components. 

Components can have ancillary information associated with them, such 
as at tribute /value pairs, anchors, or presentation information. Most hyper- 
text systems allow for attributes of components. These attributes can be 
thought of as attribute/value pairs which can be modeled as a partial func- 
tion mapping attributes to values. We thus introduce two additional given 
sets, one for the set of attribute names and the other for the set of possible 
values: 

[ATTRIBUTE, VALUE] 

The additional information associated with a base component, which was 
mentioned above, can be captured in the following schema. We include the 
invariant that anchor ids are unique within a given component, i.e., the 
number of anchors within a component is equal to the size of the set of 
(different) anchors within the component. 



-107- 



COMP^NFO 

attributes : ATTRIBUTE VALUE 
anchors : seq ANCHOR 
presentSpec : PRESENTJSPEC 

j^anchors = #(j^rsf ^ran anchors^) 



Note that a presentSpec always has some value. We introduce the function 
minlnfo which returns an instance of this schema with "minimaJ informa- 
tion," that is, no attributes, no anchors and a presentSpec which is given as 
an argument. 

minlnfo : PRESENTSPEC - COMP^NFO 

Vp5 : PRESENTSPEC • 

minInfo{ps) = (ji info : COMP-INFO \ 
info .attributes = 0 A 
info. anchors = () A 
info. presentSpec = ps) 

We use the recursive type, BASE-COMPONENT, to describe the btise 
components of a hypertext system. 

BASE-COMPONENT atom{{ATOM)) 

I link{{LINK)) 

I composite ((seq BASE-COMPONENT)) 

Finally, the schema COMPONENT represents a base component along with 
its associated information. 

COMPONENT 

compBase : BASE-COMPONENT 
camp Info : COMP-INFO 



The functions defined in the remainder of this section are there just 
to make the specification of the model easier to read and understand — 
they are not meant to have any particular significance in their own right. 
The following function builds a component given its base component and 
associated information. 



-108- 



component : BASE^COMPONENT x COMP^INFO 
COMPONENT 



component = {Xb: BASE.COMPONENT; i : COMP^NFO • 
{y. c : COMPONENT \ 
c.compBase = b A 
c.complnfo = t)) 

The following two functions extract respectively the base coniponent and 
associated information of a component. 

6056 : COMPONENT BASE.COMPONENT 
info : COMPONENT COMP^NFO 

Vc : COMPONENT • 

hase{c) = C.compBase A 
info{c) = c.complnfo 

We introduce three predicates (prefix relations) which are respectively 
true iff a component is an atom, a link, or a composite. 

is Atom _ : P COMPONENT 
isLink_ : P COMPONENT 
isComposite_: P COMPONENT 

Vc : COMPONENT • 

isAtomc O base(c) € vdniatom A 
isLinkc base{c) € ran link A 
isCompositec base{c) € ran composite 

We also define a "type" consistency relationship between components — 
that is, two components are "type consistent" is they are both atoms, both 
links, or both composites. 

_typeConsistent„: COMPONENT ^ COMPONENT 

Vci,C2 : COMPONENT • 
Ci typeConsistent C2 <^ 

(is Atom c\ A is Atom C2) V 
(isLink Cj A isLink cj) V 
(isComposite ci A isComposite C2) 

Because link components are referred to quite frequently in what follows, 
we introduce the schema LinkComp so we can define variables of that type. 



-109- 



LinkComp „„ 

COMPONENT 

compBase G ran link 



We also introduce some helpful functions to extract the various parts 
that make up a base component type. The first two functions are only 
defined for link components and return respectively the set of component 
specs for the link and the set of anchor ids for the link. 

componentSpecs : LinkComp F COMPONENT JSPEC 
anchor Specs : LinkComp -++ F ANCHOR— ID 

V c : LinkComp « 

componentSpecs{c) = {cs : COMPONENT^PEC | 
3 5 : i^,X).{link'^ {base{c))). specifiers » 
cs — s.cornponentSpec] A 
anchorSpecs{c) = {as : ANCHOR J[D \ 
• ' 3 s : Tdin{link'^{base{c))). specifiers 9 

as — s .anchorSpec] 

The next two functions are defined for any component and return respec- 
tively its attributes and its anchors. 

attributes : COMPONENT - {ATTRIBUTE ^ VALUE) 
anchors : COMPONENT F ANCHOR 

V c : COMPONENT • 

attribuc€s{c) — {info(c)). attributes A 
anchors{c) ~ T?Ln{info(c)}. anchors 

Finally, we introduce a function which given a component returns a 
component just like the given one except that the attributes function is 
(possibly) overwritten with a new value for a given attribute. 



-110- 



modify Attribute : COMPONENT x ATTRIBUTE x VALUE 

COMPONENT 



modifyAtthbute = (A c : COMPONENT; a : ATTRIBUTE; 

V : VALUE • 
(/i c' : COMPONENT | 3 », i' : COMPLIN FO \ 
i ~ info{c) • 
i' .attributes = i. attributes ® {a »• u} A 
i'. anchors = i. anchors A 
i' .presentSpec = i.presentSpec A 
c' = compon€nii;(6a5€(c), ?'))) 

Components can have sub-components and the same component may be 
a sub-component to more than one component. This relationship will be 
denoted by _subcomp_ and is defined below. 

_subcomp_: COMPONENT ^ COMPONENT 

Vci,C2 : COMPONENT • 
Ci subcomp Cj O 

bas€{ci) G Ta.n{composite^(bas€(c2))) 

A hypertext system, modeled by the schema PROTO-HYPERTEXT, 
has three parts. (1) The set of components represents the traditional "nodes" 
and "links" of a hypertext system. (2) A partial function termed the resolver 
returns the DID for a given component specifier. Note that more than one 
specifier may return the same UID. (3) To actually get hold of a component, 
we introduce an accessor function which given a UID returns a component. 
Note that this function while partial, is invertible. 

PR O TO^ YPER TEX T 

components : F COMPONENT 
resolver : COMPONENT^PEC UID 
accessor : UID COMPONENT 



To identify those links resolving to a given component, we introduce the 
function linksTo which, given a hypertext system and the UID of a compo- 
nent in the system, returns the UIDs of links resolving to that component. 



-Ill- 



linksTo : PROTO-HYPERTEXT x UID F UID 



linksTo = iXH : PROTO.HYPERTEXT; u : UID • {uid : UID \ 
{3comp : LinkComp | comp 6 H .components * 
uid = H .accessor" (comp) A 
{3 s • COMPONENT ^PEC \ 
s € componentSpecs{comp) * 
u = H .r€solv€r{s)))}) 

There are four constraints which must be satisfied by an instance of the 
schema PROTOJYPERTEXT before we can caU it a HYPERTEXT. 

• The accessor function must yield a value for every component. Be- 
cause this function is invertible, every component must then have a 
UID. 

• The resolver function must be able produce all possible valid UIDs. 

• There are no cycles in the component-subcomponent relationship, that 
is no component may be a subcomponent (directly or transitively) of 
itself. 

• The anchor ids of a component must be the same as the anchor ids of 
the component specifiers of the links resolving to the component. 



H YPERTEX T . . 

PR O TOJfl YPER TEX T 

Vc : components o c € ran accessor 
ran resolver = dom accessor 
Vc : components* (c,c) ^ (_subcomp_)* 
V c : components • 3 lids : F UID | 

lids = linksTo{ePROTOJYPERTEXT, accessor-- {c)) • 

first ^anchors{c)) = 

\J{{anchor Specs o accessor)^ltdsl) 



2.3 Adding New Components 

In this section the model adding a new component to a hypertext. The 
last function defined in this section, Create Nexv Component, is the function 
actually called from the run-time layer and is also part of the external view 



-112- 



of the model. (See the section on conformance with the reference model for 
more about this external view.) 

Adding a new component to the hypertext is given by the following 
function. It ensures that the range of the accessor function is extended to 
include the new component. The resolver function is also extended so that 
there is at least one specifier for the new component's corresponding UID. 

create Component : HYPERTEXT x COMPONENT 

HYPERTEXT 



^H : HYPERTEXT] c : COMPONENT • 
3 H' : HYPERTEXT \ 

H' .components = H .components U {c} A 
(3j uid : UID • 

(3 componentSpec : COMPONENT-SPEC • 
H' .accessor = H .accessor U {uid y-* c} A 
H' .resolver = H. resolver U 

{componentSpec >-* nid})) • 
createComponent{H , c) — H' 

The functions for creating a new node, link, and composite respectively 
are given below. They use the function createComponent described above. 

createAtomicComponent : HYPERTEXT x ATOM 

X PRESENT-SPEC - HYPERTEXT x COMPONENT 



Vi7 : HYPERTEXT] a : ATOM; ps : PRESENT-SPEC • 

3 c : COMPONENT \ c — component{atom{a)., minInfo{ps)) • 
create AtomicC omponent{H , a, ps) = 
{createComponent{H , c), c) 

In creating a link, we must ensure that all of its component specifiers re- 
solve to existing components. To test for such consistency among links we 
introduce the following link consistency predicate as a prefix relation. 



-113- 



linkConsistent. : P HYPERTEXT 



^ H : HYPERTEXT • 
linkConsistent H ^ 

(yi : LINK; s : SPECIFIER \ 

(3 cl : LinkComp \ cl € H .components • 

/ = link^{bas€(cl))) A 
5 € ran I. specifiers • 

(3 c : COMPONENT \ c e H .components • 

{H .accessor o H .resolv€r){s.componentSpec) = c)) 

Creating a new link component is then given by the following function. 

createLinkComponent : HYPERTEXT x LINK x PRESENT^PEC 
HYPERTEXT x COMPONENT 



: HYPERTEXT; I : LINK; ps : PRESENT^PEC • 
3 ^' : HYPERTEXT; c : COMPONENT \ 
c — compon€nt(link{l).,minInfo{ps)) A 
H' = create Compon€nt{ H ,c) A 
create LinkComponent{H I, ps) = {H',c) • 
linkConsistent H' 

In creating a composite we must ensure that any subcomponents of the new 
composite are already in the hypertext. 

create Composite Component : 

HYPERTEXT x seq BASE-COMPONENT 

xPRESENT-SPEC - HYPERTEXT x COMPONENT 



: HYPERTEXT; s : seq BASE.COMPONENT; 

ps : PRESENT^PEC • 
3 newComp : COMPONENT \ 

newComp = component{composite{s) , minInfo{ps)) • 
createCompositeComponent{H , s,ps) = 

{createComponent{H , newComp), newComp) A 
(Vc : COMPONENT | base{ c) G ran 5 • 
c € H .components) 

We package creating a new component with the following function. This 
is the function which will ultimately be invoked from the run- time layer. 



-114- 



Create NewComponent : HYPERTEXT x BASE.COMPONENT 
xPRESENT_SPEC HYPERTEXT x COMPONENT 



V/f : HYPERTEXT; be : BASE.COMPONENT; 
ps : PRESENTJSPEC • 
((3 a : ATOM • be = atom{a)) 

Create Ne wComponent( H , be, ps) = 

createAtomicComponent(H , atom'' {be), ps)) A 
((3 / : LINK • be = link{l)) =^ 

Create NewComponent( H , bc,ps) = 

createLinkComponent{H , link'" (be) , ps)) A 
((3 s : seq BASE^COMPONENT • be = compositei s)) =^ 
Create NewComponent{ H , be, ps) — 

ereateCompositeComponent{H , composite'" {be) , ps)) 

2.4 Deleting A Component 

In deleting a component we must ensure that we remove any links whose 
specifiers resolves to that component. 

DeleteComponent : HYPERTEXT x UID ^ HYPERTEXT 

DeleteComponent = {X H : HYPERTEXT; nid : UID • 
{fi H' : HYPERTEXT \ 3 uids : f UID \ 
uids = {uid} U linksTo{H ,uid) • 

H' .components = H .components \ H .accessor\uids) A 
H' .accessor = uids H .accessor A 
H' .resolver = H .resolver ^ uids)) 

2.5 Modifying Components 

In modifying a component we require that its associated information remain 
unchanged, that its type (atom, link, or composite) remain unchanged, and 
that the resulting hypertext remains link consistent. 



-115- 



ModifyComponent : HYPERTEXT x UID x COMPONENT 

^ HYPERTEXT 



Viy : HYPERTEXT] uid : WZ); c' : COMPONENT • 
3c: COMPONENT; H' : HYPERTEXT \ 
c - H .accessor{uid) A 

H' .components — H .components \ {c) U {c'} A 
H' .accessor = H .accessor ^ {uid ^ c'} A 
H' .resolver = H .re solver A 
m/o(c') = in/o(c) A 
c typeConsistent c' A 
linkConsistent ^' • 
ModifyComponent{H ,uid,c) = H' 

2.6 Retrieving A Component 

To retrieve a component, given its UID, means just to have the returned 
value of the accessor function. 

getComponent : HYPERTEXT x UID ^ COMPONENT 

^H : HYPERTEXT; uid : WZ) • 

getComponent{ H , uid) = H .accessor [uid) 

Given a UID which happens to represent a linii, there exist operations 
which return either a source or destination specifier for that component. 

2.7 Attributes 

We introduce functions to both get and set the value of a given attribute (if 
it exists) for a given component. 

AttributeValue : HYPERTEXT x UID x ATTRIBUTE ^ VALUE 

^H : HYPERTEXT; uid : UID; a : ATTRIBUTE • 
(3 c: COMPONENT | c = H .accessor{uid) • 

Attribute Value{H , uid, a) = attributes{c){a)) 



-116- 



SetAttributeValue : HYPERTEXT x UID x ATTRIBUTE x VALUE 

HYPERTEXT 



SetAttributeValue = 

{XH : HYPERTEXT; uid : UID; a : ATTRIBUTE; 

V : VALUE • 
(/i ^' : HYPERTEXT | 3 c, c' : COMPONENT • 
c = H .accessor {uid) A 
c' = modify Attribute{c, a, v) A 
H'. components — H .components \ {c} U {c'} A 
H' .accessor = H .accessor Q {uid c'} A 
H' .resolver = H .resolver)) 

There is aJso a function which returns the set of all component attributes. 

AllAttHbutes : HYPERTEXT -> F ATTRIBUTE 

^H : HYPERTEXT • 

AllAttributes{H) = {a : ATTRIBUTE \3c: COMPONENT • 
a € dom(attributes{c))} 

2.8 Anchors 

It is sometimes useful to know the link components which are associated 
with a particular anchor. The function LinksToAnchor returns the set of 
link component uids associated with a particular anchor id for a particular 
component id, 

LinksToAnchor : HYPERTEXT x UID x ANCHORED - F UID 

LinksToAnchor = 

(A^ : HYPERTEXT; u : UID; aid : ANCHORED • 
{lid : UID\3 lids : f UID \ 

lids = linksTo(H , u) A lid € lids • 

aid 6 {anchorSpecs 0 H .accessor)(lid)}) 



-117- 



3 Simple Runtime Layer Model 



3.1 An Overview of the Runtime Layer 

The fundamental concept iu the runtime layer is the instantiation of a com- 
ponent. An instantiation is a presentation of the component to the user. 
Operationally, an instantiation should be thought of as a kind of runtime 
cache for the component. A 'copy' of the component is cached in the in- 
stantiation, the user views and/or edits this instantiation, and the altered 
cache is then 'written' back into the storage layer. Note that there can be 
more than one simultaneous instantiation for any given component. Each 
instantiation is assigned a unique (within session, see below) instantiation 
identifier (IID). 

Instantiation of a component also results in instantiation of its anchors. 
An instantiated anchor is known as a link marker. This terminology is con- 
gruent with that used in Intermedia, where the term "anchor" refers to an 
attachment point or region and the term "link marker" refers to the visible 
manifestation of that anchor in a displayed document. In order to accomo- 
date the link marker notion within the model, an instantiation is actually 
a complex entity containing a feci^e instantiation together with a sequence 
of link markers and a function mapping link markers to the anchors they 
instantiate. A base instantiation is a primitive in the model that represents 
some sort of presentation of the component to the user. 

At any given moment, the user of a hypertext can be viewing and/or edit- 
ing any number of component instantiations. The runtime layer includes an 
entity called a session which serves to keep track of the moment-by-moment 
mapping between components and their instantiations. Specifically, when a 
user wants to access a hypertext, he or she opens a session on that hyper- 
text. The user can then create instantiations of components in the hypertext 
(an action known as "presenting" the component). The user can edit these 
instantiations, can modify the component based on the accumulated edits 
to the instantiation (an action known as "realizing" the edits), and finally 
can destroy the instantiation (an action known as "unpresenting" a compo- 
nent). When the user is finished interacting with the hypertext, the session 
is closed. 

In the model, the session entity contains the hypertext being accessed, 
a mapping from the IIDs of the session's current instantiations to their 
corresponding components in the hypertext, a history, a runtime resolver 
function, an instantiator function, and a realizer function. At any given 



-118- 



moment, the history is a sequence of all operations carried since the last 
open session operation. In the present version of the model, this history is 
used only in defining the notion of a read-only session. It is intended to 
be available, however, to any operation that needs to be conditionalized on 
preceeding operations. 

The session's runtime resolver function is the runtime version of the stor- 
age layer's resolver function. Like the resolver, it maps specifiers into com- 
ponent UIDs, The runtime resolver, however, can use information about 
the current session, including its history, in the resolution process. The 
storage resolver layer has no access to such runtime information. For exam- 
ple, a specifier may refer to "the most recently accessed component named 
'xyzzy' The runtime resolver is responsible for mapping this specifier into 
the UID matching this specification. The storage layer resolver would not 
be able handle this specification. The runtime resolver is restricted to be a 
superset of the storage layer resolver function; any specifier that the storage 
layer resolver can resolve to a UID must be resolved to the same UID by the 
runtime resolver. 

At the heart of the runtime model is the session's instantiator function. 
Input to the instantiator consists of a component (UID) and a presentation 
specification. The instantiator returns an instantiation of the component as 
part of the session. The presentation specification is primitive in the model, 
but is intended to contain information specifying how the component being 
instantiated is to be "presented" by the system during this instantiation. 
Note that the component itself has a presentation specification from the 
storage layer of the model. This presentation specification is meant to con- 
tain information about the component's own notion of how it should be 
presented. It is the responsibility of the instantiator function to adjudicate 
(by selection or combination or otherwise) among the presentation specifi- 
cation passed to the instantiator and the presentation specification attached 
to the component being instantiated. The model in its current form does 
not maJie this adjudication explicit. 

The instantiator function is the core of a the present component op- 
eration. Present component takes a component specifier (together with a 
session and a presentation specification) and calls the instantiator using the 
component UID derived from resolving the specifier. Present component 
in turn is the core of the follow link operation. Follow link takes (the IID 
of) an instantiation together with a link marker contained within that in- 
stantiation. It then presents the component(s) that are at the destination 
endpoints (i.e., endpoints whose specifier has direction of TO) of all link(s) 



-119- 



that have as an endpoint the anchor represented by the given link marker. 
In the case where all links are binary, this is equivalent to following a link 
from the link marker for its source. The result of following the link is a 
presentation of its destination component and anchor. 

The instantiator function also has an "inverse" function called the real- 
izer function which takes an instantiation and returns a (new) component 
that "reflects" the current state of the instantiation (i.e., including recent 
edits to the instantiation). This is the basic mechanism for "writing back 
the cache" after an instantiation has been edited. The component produced 
by the realizer is used as an argument to the storcige layer modify com- 
posite operation to replace the component with the edited component. This 
operation is wrapped in the function called realize edits in the runtime layer. 

3.2 Formalization of the Runtime Layer 

The runtime model depends on the notion of an instantation which is the 
visual representation of some component. Each instantiation has a unique 
instantiation id from the given set IID. 

[IID] 

An instantiation consists of a base instantiation which "represents" a com- 
ponent, a sequence of link markers which "represents" the anchors of the 
component, and a function mapping link markers to anchor ids. 

[BASE.INSTANTIA TION, LINK A RKER] 

INSTANTIA TION 

base : BASEJNSTANTIATION 

links : seq LINK^KfARKER 

link Anchor : LINKJ^ARKER ANCHOR -ID 

dom linkAnchor = ran links 



A user manipulates instantiations, so that there must be a way of map- 
ping from instantiations to components. The function variable instants in 
the SESSION schema defined below maps an instantiation id to a pair con- 
sisting of an instantiation and the UID of its corresponding component. 
The accessor function in the HYPERTEXT schema then maps these UIDs 



-120- 



to components. More than one instantiation may be associated with the 
same UID and hence with the same component. 

A hypertext is manipulated in a session which is model by the SESSION 
schema. The OPERATION free type names the various operations a user 
can perform during a hypertext session. 

OPERATION ::= OPEN \ CLOSE 

I PRESENT I UNPRESENT 

I CREATE I EDIT \ SAVE \ DELETE 

During a session, a user opens up one or more instantiations of hypertext 
components through which the hypertext may be modified. We use the term 
presents to denote opening up an instantiation on a component because the 
component is presented to the user by means of the instantiation. Instanti- 
ations are not only a function of the component which they represent, and 
two presentation specifiers — one implicitly from the component's complnfo 
and the other explicitly, either user given or from a link specifier — but also 
implicitly of the "current" set of instantiations. The function instantiator 
which is part of the schema SESSION captures this relationship. In sav- 
ing the result of a series of edits, the reverse of the instantiator function is 
needed; we call this function a realizer function. It takes an instantiation 
and returns a component based on the current session. 

There are some component specifiers which can only be resolved at run- 
time. An example of such a specifier is "the last node visited." The storage 
layer should be independent of such component specifiers. We introduce 
the notion of a run-time resolver which is just an extension of the regular 
resolver function. Note that the invariants on anchors given in the schema 
for HYPERTEXT only apply to those component specifiers which are in 
the domain of H .resolver. Also the LinksToAnchor function will not give 
those links with component specifiers resolvable only at run-time (not in 
the domain of H .resolver) — these additional links must be captured in the 
run-time layer. 



-121- 



SESSION 

H : HYPERTEXT 

history : seq OPERATION 

instants : IID >^ {INSTANTIATION x UID) 

instantiator : UID x PRESENT^PEC INSTANTIATION 

realizer : INSTANTIATION ^ COMPONENT 

runTimeResolver : COMPONENT^PEC UID 

head{history) = OPEN 
V uid : UID; ps : PRESENT ^SPEC \ 
uid € ^om H .accessor • 

realizer {instantiator{md,ps)) = H .accessor{uid) A 
H .resolver C runTimeResolver 



A SESSION 

SESSION 
SESSION' 

^history' = history -\- 1 
instantiator' = instantiator 
realizer' = realizer 



A session begins with an existing hypertext (storage system) and a clean 
instantiation slate. 

openSession 

SESSION 

hypertextl : HYPERTEXT 

H = hypertext'] 
history = {OPEN) 
instants = 0 



Because there are several operations which can open up a new instan- 
tiation, we introduce the following function which opens up a set of new 
instantiation on an existing set of component. 



-122- 



openComponents : 

SESSION X V {SPECIFIER x PRESENT ^PEC) 
- SESSION 

V5 : SESSION; specs : f (SPECIFIER x PRESENT ^PEC) • 
3 5' : SESSION; iids :¥ IID; 

new Instants : IID >+♦ (INSTANTIATION x f//Z)) | 
5'.^ = 5.F A 

S' .runTimeResolver = S .runTimeResolver A 
S'. history = S. history ^ (PRESENT) A 
S' .instants = S. instants © newlnstants A 
#n'ds = i^specs A ifds fl dom S. instants = 0 A 
dom newlnstants = iids A 
(V 5 : 5pec5 • 

3 iid : nrfs; uicf : UID; 

cs : COMPONENT-SPEC; 
ps : PRESENT-SPEC; 
inst : INSTANTIATION \ 

cs = {first(s)).componentSptc A 

p5 = 5econ<i(5) A 

uid = S .runTimeResolver(cs) A 

I'risi = S .instantiator(uid,ps) • 

newlnstants{iid) = (inst, uid)) • 
openComponents(S y specs) = 5' 



—pre sent Component 

spec? : SPECIFIER 
presentSpecl : PRESENT SPEC 

eSESSION' = 

openComponents(6 SESSION ,{(spec1 , presentSpecl)]) 



We can also follow a link from a given link marker in a given instantiation 
and present all the components for which the associated link(s) has(have) 
specifiers with a "TO" direction. There may be more than one link involved 
because there may be more than one link associated with a particular anchor. 



-123- 



foUowLink 

A SESSION 
iidl : IID 

linkMarkerl : LINKJ^ARKER 

3 aid : ANCHORED; links : F LinkComp- 

specs : ¥ {SPECIFIER x PRESENT-SPEC) | 
aid = {first{instants{iidl))).linkAnchor{linkMarker?) A 
links = H .accessor^LinksToAnchor{n , 

s€cond{instants{iid'!)), aid)^ A 
^rsi^5pecs[| = {s : SPECIFIER \ 3 linkc : LinkComp \ 

linkc G links • 5 € ran(/mA;~(6a5e(/m^c))).sp€CJ_/zer5} A 
(Vs : spec5 • {first{s)). direction = TO A 

second{s) = {fiTst{s)).presentSp€c) • 
eSESSION' = 

op€nCompon€nts{d SESSION , specs) 



Opening up a new instantiation on a newly created component is mod- 
eled by the newComponent schema. 

newComponent 

A SESSION 

component : COMPONENT 
baseComp'^ : BASE.COMPONENT 
psi : PRESENT-SPEC 
presentSpecl : PRESENT-SPEC 

history' = history " (CREATE) 

{H' , component) = CreQteNewComponent{n ,baseComp1 ,ps1) 
3 uid : UID; xnst : INSTANTIATION; iid : IID \ 
iid ^ dom instants • 

inst = instantiator{uid . presentSpec?) A 
uid = H' .accessor^ {component) A 
instants' =: instants © {I'lirf (m5<, 



The schema unPresent models the removal of an instantiation. 



-124- 



unPresent 

ASESSION 
iidi : I ID 

H' = H 

history' = history ^ { UNPRESENT) 
instants' = {iidl} ^ instants 



Instantiations can be modified by editing them. Editing an instantiation 
does not cause a change in its corresponding component. An explicit save 
operation is required to save the result of an edit (or many edits). 

editlnstantiation 

ASESSION 

instantiation! : INSTANTIATION 
iidi : IID 

H' = H 

history' = history ^ (EDIT) 
iidi € dom instants 
instants' = instants® 

{iidi ^-+ {instantiation? , s€cond{instants{iid'!)))} 



realizeEdits 

ASESSION 
iidi : IID 

history' = history {SAVE) 
instants' — instants 

3 c : COMPONENT; inst : INSTANTIATION; uid : UID 
inst = first{instants{iidl)) A 
uid = s€Cond{instants{iid'!)) A 
c = realizer{inst) • 
H' = ModifyComponent{ H , uid,c) 



To be complete we must allow a component to be deleted. Since a 
component is identified by its instantiation, the component to be deleted 
must have been instantiated. We also must remove any other instantiations 
for that component. 



-125- 



deleteComponent 

^SESSION 
iidl : IID 

history' history ^ {DELETE) 
iid'^ € dom instants 

3 uid : UID j uid - second{instants{%id1)) • 
H' = DeleteComponent{H , uid) A 
instants' — {jttf?} instants 



A session finlly ends when it is closed out. Notice that the default is not 
to save the results of any changes to instantiations. 

closeSession 

A SESSION 

H' = H 

history' = history (CLOSE) 
instants' = 0 



We can model a read-only SESSION with the following schema: 

RE A D.ONL Y -SESSION 

SESSION 

{SA VE, CREA TE, DELETE} n ran history = 0 



4 Conformance with the Reference Model 

One reason to have a reference model for hypertext is to try to answer the 
ascertain whether a purported hypertext system actually warrants being 
called a hypertext system. So, given an actual hypertext system how do we 
show that it meets, or is conformant with the model? The best guidance for 
answering this question comes from the VDM experience under the heading 
of data reification as described, for example, in Chapter 8 of Cliff Jones' 
book [13] on software development using VDM. First, we must exhibit total 
functions, called retrieve functions which map the actual types and functions 
from given (actual) hypertext system to each of the following types and 
functions of the model. We must also demonstrate adequacy - that there 



-126- 



is at least one actual representation for each abstract value. Obviously, the 
retrieve functions must satisfy the invariants which are given for the data 
types and functions. An informal way of saying this is that everything which 
is expressible or realizable in the model must be expressible or realizable in 
the actual system. 

In actuality our model is much more powerful than necessary. In partic- 
ular 

• By admitting multi-way links and links to links in the model, we put 
a fairly heavy burden on any implementation. 

• Many hypertext systems do not have the notion of composites. 

• Some hypertext systems, such as KMS, do have not have links with 
both an explicit source and destination. Thus requiring discrimination 
amongst all the values of type DIRECTION is too much. 

We are currently working on a "minimal" model which address the above 
items and others as may be necessary. 

The following list summarizes the given sets (base types), abstract types, 
functions, and operations which must have actual realizations in a hypertext 
system conforming to the model. 

1. GivenSets. 
UID 

COMPONENT-SPEC 

PRESENT-SPEC 

ANCHOR-ID 

ANCHOR^VALUE 

ATOM 

ATTRIBUTE 

VALUE 

IID 

BASE-INSTANTIATION 
LINK-MARKER 

2. Abstract types. 



-127- 



DIRECTION 
ANCHOR 

SPECIFIER 
LINK 

COMP_INFO 

BASE_COMPONENT 

COMPONENT 

HYPERTEXT 

INSTANTIATION 

OPERATION 

SESSION 

3. Storage layer functions. 

CreateNewComponent 

DeleteComponent 

ModifyComponent 

AttributeValue 

SetAttributeValue 

AIlAttributes 

LinksToAnchor 

4. Runtime layer operations (schemas). 

openSession 

present Component 

followLink 

newComponent 

unPresent 

editlnstantiation 

realizeEdits 

deleteComponent 

closeSession 



-128- 



5 Concluding Remarks 



Development of the Dexter model is still in its very early stages. As discussed 
in Section 4, the model as currently stated is far more powerful than any 
existing hypertext system. The provisions for n-ary links and for composite 
nodes, for example, are intended to accomodate the design of future hyper- 
text systems. No existing system that we have examined includes both n-ary 
links and composite nodes. The result is that no existing system 'conforms 
to' the model in the sense that it supports all of the mechanisms that the 
model supports. The solution to this problem is to make some mechanisms 
'optional', resulting in a family of interrelated models that support differing 
sets of optional mechanisms. The weakest model, for example, would have 
no composites and only binary links. The strongest model would be the 
Dexter model in the present form. Conformance to the model could then be 
condition alized on the exact set of mechanisms supported. Systems would 
be compared on the basis of the set of mechajiisms that they do support. 

A related issue involves a number of consistency restrictions that the 
present model imposes. For example, when creating a link the model re- 
quires that all of its specifiers resolve to existing components. This restric- 
tion prevents the creation of links that are 'dangling' from the outset. The 
model does not, however, include any restrictions that prevent the creation 
of dangling links via the deletion of linked-to components. This restriction 
adequately represents the consistency guarantee of KMS. But its is overly 
restrictive for Augment, which allows creation of initially dangling links. In 
contrast, its is not restrictive enough for NoteCards and HAM which pre- 
vent dangling links at all times. As in the case of mechanisms, restrictions 
of this sort will have to be made optional in the model. Conformance to the 
model can then be conditionalized on appropriate choices of restrictions. As 
in the case for mechanisms, systems can compared on the basis of the set of 
restrictions that they enforce. 

The model has yet to be compared in detail to the hypertext systems 
it is designed to represent. Clearly, a necessary step in the development 
of the model is to formally specify (in Z) the architecture ajid operation 
of a number of 'reference' hypertext systems using the constructs from the 
Dexter model. These reference systems should be chosen to represent a 
broad spectrum of designs, intended application domains, implementation 
platforms, etc. This enterprise would provide valuable feedback regarding 
the adequacy and completeness of the model. In particulaj, it will help 
asess whether the model provides sufficient mechanisms for representing the 



-129- 



<hyp«rtext> 

<coBpon«nt> 

<type> text </typ«> 
<uid> 21 </uid> 

<diata> This is soa« t«zt .... </data> 
<anchor> 

<id> 1 </id> 

<location> 13 </location> 

</anchor> 
</co«ponent> 
<coHponent> 

<type> text </typ«> 

<uid> 777 </uid> 

<data> This is son* other text .... </data> 
<anchor> 

<id> 1 </id> 

<location> 13-19 </location> 
</anchor> 
</coiq>on«nt> 
<C0Bf>onent> 

<typ«> link </typ«> 
<uid> 881 </uid> 
<sp«cifier> 

<coBponent_uid> 21 </coBponent_uid> 
<anchor_id> 1 </anchor_id> 
<direction> FROM </direction> 
<\8pacifier> 
<specif i«r> 

<coi«ponent_uid> 777 </component_uid> 
<anchor_id> 1 </anchor_id> 
<direction> TO </direction> 
<\8p«cif ier> 
</co«ponent> 
</hypertext> 



Figure 5: Example of a trivial interchange format derived from the model. 

important (common) abstractions found in the reference systems. It will 
also provide feedback on the 'naturalness' of the model, i.e., on whether 
the specification of the reference systems in Dexter terms feels 'natural' 
or whether the abstractions found in certain systems must be excessively 
massaged to fit into the Dexter abstractions. 

Despite its early stages of development, the model has already been 
useful in developing hypertext interchange standards. As described in the 
panel on interchanging hypertexts at the Hypertext 89 Conference [16], a 
number of efforts have been started to operationalize the abstractions of 
the Dexter model in the form of interchange formats. Figure 5 shows an 



-130- 



example of one such format. This format was used for experimenting vv., 
the interchange of hypertexts between NoteCards and HyperCard. As can 
be seen from the figure, the format is a fairly straightforward rendering of 
the entities found in the Dexter model into a SGMLish syntax. This format 
is by no means a well- developed interchange standard. But it does suggest 
that the Dexter model provides a good basis from which to develop such 
standards. In fact, because the model is an attempt to provide a well-defined 
and comprehensive model, it is an ideal basis for developing a comprehensive 
standard for interchanging hypertexts between widely differing systems. 



-131- 



References 



[1] Akscyn, R., McCracken, D.L., Yoder, E.A. KMS: A distributed hy- 
pertext for managing knowledge in organizations. Communications of 
the ACM, 31(7), 1988, 820-835. 

[2] Campbell, B. & Goodman, J.M. HAM: A general purpose hypertext 
abstract machine. Communications of the ACM, 31(7), 1988, 856-861. 

[3] Conklln, J. Hypertext: A survey and introduction. IEEE Computer, 
20(9), 1987, 17-41. 

[4] Delisle, N. & Schwartz, M. Neptune: a hypertext system for CAD ap- 
plications. Proceedings of ACM SIGMOD '86, Washington, D.C., May 
28-30, 1986, 132-142. 

[5] Englebart, D.C. Authorship provisions in Augment. Proceedings of the 
IEEE COMPCON, Spring, 1984, 465-472. 

[6] Englebart, D.C. Collaboration support provisions in Augment. OAC 
Digest: Proceedings of the 1984 AFIPS Office Automation Conference, 
Los Angeles, February 20-22, 1984, 51-58. 

[7] Feiner, S., Nagy, S., & van Dam, A. An experimental system for creating 
and presenting interactive graphical documents. ACM Transactions on 
Graphics, 1(1), 1982, 59-77 

[8] Goodman, D. The Complete HyperCard Handbook. New York: Bantam 
Books, 1987. 

[9] Halasz, F.G., Moran, T.P., & Trigg, R.H. NoteCards in a nutshell. Pro- 
ceedings of the 1987 ACM Conference of Human Factors in Computer 
Systems (CHI+GI '87), Toronto, Ontario, April 5-9, 1987, 45-52. 

[10] Halasz, F.G. Reflections on NoteCards: Seven issues for the next gen- 
eration of hypermedia systems. Communications of the ACM, 31(7), 
1988, 836-855. 

[11] Proceedings of Hypertext 87, Chapel Hill, NC, November 13-15, 1987. 
Available from ACM Press, order number 608892. 

[12] Proceedings of Hypertext 89, Pittsburgh, PA, November 5-8, 1989. 
Available from ACM Press, order number 608891. 



-132- 



[13] Jones, C.B. Systematic Software Development Using VDM. Prentice- 
Hail International, Hertfordshire, England, 1986. 

[14] Lange, D.B. A formal approach to hypertext using post-prototype for- 
mal specification. Dept. of Computing Science, Technical University of 
Denmark, Oct. 31, 1989. 

[15] Meyrowitz, N. Intermedia: The architecture and construction of an 
object-oriented hypermedia system and applications framework. Pro- 
ceedings of the Conference on Object-oriented Programming Systems, 
Languages, and Applications (OOPSLA '86), Portland, OR, Septem- 
ber 29 - October 2, 1986, 186-201. 

[16] Oren, T. Panel: Interchanging hypertexts. Proceedings of Hypertext 89, 
Pittsburgh, PA, November 5-8, 1989, 379-381. 

[17] Pearl, A. Sun's Link Service: A protocol for open linking. Proceedings 
of Hypertext 89, Pittsburgh, PA, November 5-8, 1989, 137-146. 

[18] Shneiderman, B. Hypertext on Hypertext. Addison-Wesley: New York, 
1989. 

[19] Spivey, J.M. The Z Notation. Prentice-Hall International, Hertford- 
shire, England, 1989. 

[20] Trigg, R.H. & Weiser, M. TEXTNET: A network-based approa<:h to 
text handling. ACM Transactions on Office Information Systems, 4(1), 

1986, 1-23. 

[21] Walker, J. Document Examiner: Delivery interface to hypertext docu- 
ments. Proceedings of Hypertext 87, Chapel Hill, NC, November 13-15, 

1987, 307-323. 

[22] Walker, J. Supporting document development with Concordia. IEEE 
Computer, 21(1), 1988, 41-59. 

[23] Yankelovich, N., Haan, B., Meyrowitz, N., k Drucker, S. Intermedia: 
The concept and the construction of a seamless information environ- 
ment. IEEE Computer, 21(1), 1988, 81-96. 



-133- 



STANDARDIZATION OF HYPERMEDIA: 
WHAT'S THE POINT? 



A Position Paper 

Hypertext Standardization Workshop 

National Institute of Standards and Technology 
National Computer Systems Laboratory 
January 16-18, 1990 



Shoshana L. Hardt-Komacki, Louis M. Gomez, John F. Patterson 

Bellcore 
445 South Street 
Morristown, NJ 07960-1910 
(201) 829-4528 shoshi@bellcore.com 



Abstract 

In this paper we present multiple views on the issue of standardi- 
zation of Hypermedia systems that operate over a global hetero- 
geneous information network. To aid our analysis we introduce 
a reference model that captures the information flow and the 
information control aspects from Ae viewpoint of the user. This 
model is then used to focus the analysis of Hypermedia systems 
from a variety of perspectives, such as overall resources, network 
communication, interface building, and application writing. 
Based on our analysis we conclude that at this time, the com- 
ponents of Hypermedia systems that are ready for standardiza- 
tion are not necessarily Hypermedia- specific. Moreover, we 
strongly believe that the Hypermedia-specific aspects of these 
systems are not yet ready for standardization and we question the 
wisdom of ever standardizing certain Hypermedia specific com- 
ponents such as the user interface or the navigation tools. In 
addition, we conjecture that it may be desirable to standardize a 
generic set of tools that can be used to build these components so 
as to guarantee that the access to the information stored in future 
Hypermedia systems will not be impaired. 



-135- 



ANGLES ON STANDARDIZATION 



Intrinsic to the quest for standardization is the desire to make artifacts designed by different peo- 
ple in different places at different times compatible in relation to some predefined tasks. If we 
ask why one should attempt to standardize HyperText and Hypermedia technologies, we should 
look for the answer in efforts to combine pieces of information, text, graphics, still images, 
audio, video, animation and the like, which were created by different people in different places 
at different times. From this perspective it follows that it is reasonable to consider such standard- 
ization efforts only if we are willing to view the system as operating on a veiy large heterogene- 
ous network. 

Multimedia is a very complex artifact. It requires large amounts of resources and human 
involvement. Because of its potential as a new medium in which the human can seek, express 
and control knowledge, human interface consideradons are of crucial importance. Much of the 
complexity involved in running the support hardware and software that make Hypermedia sys- 
tems a reality must remain hidden from the human and should proceed automatically. This 
implies the smooth and efficient transfer of information and control between many machines, 
each with its own capabilities for communication and information handling. Furthermore, it 
implies that the overall speed of the composite system should remain mostly unaffected by the 
global configuration of the various information sources and conduits to enable synchronization. 

The standardization of an artifact as complex as Hypermedia involves the standardization, or at 
least a thorough understanding, of the evolutionary trends existing today in the Hypermedia sup- 
porting technologies. Any attempts to freeze a version of a rapidly evolving system should be 
carefully engineered so as to guarantee uninterrupted progress. Therefore, one of the more 
important challenges is to decide which aspects of Hypermedia need to become a standard and 
which aspects are better off left alone. This decision should be based on a model of the func- 
tionality of the system, a model flexible enough to allow unexpected technological develop- 
ments. To illustrate this point let us consider two extreme scenarios for Hypermedia functional- 
ity. In the first scenario a single user is running a standalone application on a workstation. In 
the second scenario a user is running a shared application, which includes real-time communica- 
tion via broadband networks with other users and with a variety of infonnation gateways to dis- 
tributed data sources. Undoubtedly, the complexity of the issue of standardization and its impli- 
cations on information sharing are of different proportions in the two scenarios. In the first case, 
standardization must guarantee the compatibility of applications in many present and future 
environments. In the second case, standardization will guarantee complete information sharing 
across authors, users and machines. It is the second scenario which can benefit the most from 
standardization and at the same time is in the most fragile developmental phase and hence 
requires special handling. 

There are at least three reasons to embark on standards efforts. First it may be valuable to come 
to some agreement on a Hypermedia independent environment which will support this brand of 
computation. Second, standards may focus on the representation of data objects use in Hyper- 
media applications. And third, a standards effort might concentrate its energy providing a stan- 
dard human interface for applications that are browsing and information retrieval intensive. 

With respect to the first point, a standard reference model which supports Hypermedia almost 



-136- 



certainly shares many, if not all, its attributes with reference models for most other applications. 
It may be useful, however, for Hypermedia practitioners to determine where, in a layered refer- 
ence model Hypermedia applications exert most of their impact. Later in this paper we outline a 
general reference model to facilitate discussion of this sort. 

Hypermedia applications are intimately concerned with data objects of various types and their 
interrelation. Because of their complex linking structure and multiple media flavor. Hypermedia 
applications, in all likelihood, require that data objects have detailed and explicit representations. 
Rich and flexible standard representations will be of great value to Hypermedia implementers in 
matters of exchange and authoring. It is also tlie case, however, that these very same objects 
(e.g. image, video) and their underlying representations are also critical to many other classes of 
applications where exchange is important but has nothing to do with Hypermedia. Therefore, we 
question the prudence of Hypermedia-based object presentation standards. It would seem that 
Hypermedia practitioners should, again, consider the unique impact that hypertext applications 
might have on current and emerging object presentation standards efforts. We offer some con- 
jectures in this regard in the context of a reference model. 

While the defining characteristic of Hypermedia is its linking structure, its most often cited 
benefit is as an aid to human intellect. It may be reasonable then, for Hypermedia practitioners to 
look for standards in the human interface to realize this cognitive benefit. We conjecture that this 
route is at best premature and at worst naive. A standard Hypermedia human interface is prema- 
ture simply because there does not exist very much solid information about the sorts of Hyper- 
media design features that people find helpful. This state of affair makes it virtually impossible 
to code high level standards which could sensibly and practically apply to the multiplicity of 
potential Hypermedia applications. Readiness aside, such a standards quest may not be prudent. 
The target domain of an application often changes fundamental qualities of its interface. Given 
the complexity of Hypermedia application domains, it may be more prudent to build highly 
stereotype applications optimized for the communication and problem solving needs of a partic- 
ular domain rather than a vanilla consistent interface that does not accommodate the rich varia- 
tion in Hypermedia applications. 

In this paper, we center our discussion around a view of the Hypermedia system from the user's 
perspective. If we follow the information and control as they flow from the user's terminal to the 
actual database, we cross at least eight functional levels. These levels are described in the next 
section, followed by an illustration of their descriptive power in two examples of prototype Mul- 
timedia systems. This illustration is followed by a discussion of the Hypermedia system from 
other perspectives and the implications of this decomposition into levels on standardization. 



A REFERENCE MODEL FROM THE USER'S VIEWPOINT 

Like many other dynamic systems with a high degree of complexity. Hypermedia can be viewed 
from multiple perspectives. Each perspective reveals a dimension along which hierarchical 
description levels can be stacked and interdependencies between structure and function revealed. 



-137- 



Level 6 


File System 






Level 5 


Virtual File System 






Level 4 




Virtual 






Presentation Objects 


Interprocesses 


Broadband 


Level 3 




Communication 






Dialogue/Applications 


Mechanism 


Network 


Level 2 


Virtual Terminal 






Level 1 


Actual Terminal 







Figure 1 

Six Plus Two Level Reference Model Describing the Passage of Information and Control 
From the User at the Actual Terminal to the Actual Information Source. We View 
Level 3 and 4 as the Only Hypermedia Specific Levels. 



Imagine the way a Hypermedia system looks from the perspective of the user. From this per- 
spective, both information and control are conveyed through layers of interpretation until they 
reach their destination which, in this case, is an arbitrary collection of actual file systems created 
by arbitrary authors and located at remote sites which may be unknown to the user. We chose to 
separate the path of information and control into eight independent layers, each with its own set 
of primitive operations and data elements. Consequently, implicit to the construction of this 
reference model is the assumption that the functionality of the overall system is decomposable. 
However, keep in mind that many complex artifacts are only nearly decomposable, namely, their 
actual implementation involves "mixing" of levels due to strong pragmatic considerations. 
Therefore, we consider this model an idealization which serves as a general guideline during 
system design and evaluation. 



-138- 



In Figure 1 we introduce the eight level model and represent it as a "six plus two" level model. 
This is because, the virtual interprocess communication mechanism and its actual network 
implementation can be involved in the information transmission process anywhere along the 
path between the actual terminal and the actual file system and hence could not be placed in any 
particular location on the stack. 

Undoubtedly, the reference model, at the level of detail shown in Figure 1, may describe any 
interactive distributed computer system. This raises the question of where do we perceive the 
Hypermedia specific components of the system to reside. In attempting to answer this question 
one may realize that any computer system, when examined very closely, exhibit many of what 
one may consider at least Hypertext specific characteristics. For example, the Unix® file system 
provides much of the functionality of a Hypertext system, without, perhaps, a sylized user inter- 
face. We will return to this point shortly, after we briefly review the levels shown in Figure 1. 

The bottom two levels in Figure 1 describe the terminal and the virtual terminal. Like all virtual 
devices, the virtual terminal provides a level of description that is implementation independent. 
The primitive operations comprising the virtual device description are implemented in every 
device to the best of that device's actual capabilities. Like all virtual devices, it represents an 
additional level of processing of information, which is the price one must pay for flexibility. 
With the virtual terminal level of description, dialogues (applications) can be constructed (level 
3) that are implementable on the virtual terminal and which have as primitive operations user 
interaction activities. The dialogue level is the "information browsing" level and the value of 
separating it from the virtual terminal level is that it enables the application writer to tailor the 
interface to the applications and to the targeted user community in a terminal independent 
fashion. The level of description of the Presentation Objects (level 4) contains packets of infor- 
mation stored in a form that can be displayed by any interface. The database containing these 
objects is represented in level 5. Notice that operations at each level in the stack except the top 
three are represented in terms of primitive operations of the level below it. In the case of the top 
three levels, which are separated in Figure 1 by a double line, the order is reversed. This is 
because the presentation objects are implemented in terms of the virtual file system, and the vir- 
tual file system is implemented in terms of the actual file system. This reversal property is an 
essential part of any description scheme that, similar to our scheme, follows the path of informa- 
tion and control between the user and some real data — the scheme has to start with a real object, 
namely the terminal, and end with a concrete implementation of data. We will not to elaborate 
on the actual implementation levels of the file system. 

Which of the above levels are part of the Flypermedia application and which levels describe the 
environment? In our work we view the Presentation Objects and the interface (levels 3 and 4) as 
part of Hypermedia and they will be discussed in more details in the next section. We view the 
other description levels as representing the supporting infrastructure for global Hypermedia sys- 
tems and for most other applications. Currendy, this supporting infrastructure is not standard- 
ized, e.g., the virtual terminal and the virtual file system are not standards, and broadband com- 
munication networks are far from standardized. Given this view, one may question, as we did in 
the first section, the wisdom of standardizing Presentation Objects and aspects of interi'aces 
before, at least, stable sketchs of a standard virtual terminal and a standard virtual file system are 
agreed upon. 



-139- 



In the next section we will examine standardization issues from various viewpoint, but before 
doing so we illustrate the value of the reference model presented in Figure 1 in two examples. 
To demonstrate how the reference model provides structure to the functionality of Hypermedia 
systems, we look at the following two systems from the domain of Customized Electronic Infor- 
mation Delivery. Customized Electronic Information Delivery systems provide users with vari- 
able information streams. Regarding the level of editing of the information items delivered by 
such systems we can imagine two extremes — highly stylized, long, magazine like, articles, and 
short raw articles directly from the news wires. The Electronic Magazine (Judd and Cruz, 1989) 
is an example of the former, and the Passive Information Grazing system (Bussey et al, 1989) is 
an example of the latter. 

The Electronic Magazine research prototype displays multimedia articles through a stylized user 
interface providing the user with navigation and orientation tools. In addition, the magazine 
contains multimedia authoring tools and a mark-up language. Figure 2 presents a glance at the 
Electronic Magazine from the perspective of the reference model presented above. 



Actual Terminal 


Sun-3 Color Monitor 


Virtual Terminal 


SunViewNvindow System 


Dialogue/Applications 


Multimedia Interface 
Navigation tools 


Presentation Objects 


Stylized Multimedia Articles 
SGML Based Mark-Up Language 
Authoring tools 


Virtual File System 


Linked Database of Multimedia Articles 


Actual File System 


Unix® Files 


Virtual InterProcess 
Communication Mechanism 


None 


Actual Network 


None 



Figure 2 

Description of the Elecfronit' Magazine Prototype 



SunView is a trademark of Sun Microsystems, Inc. 
Unix is a registered trademark of AT&T. 



-140- 



Actual Terminal 


Sun-3 Color Monitor 


Virtual Terminal 


X Window System'''' 


Dialogue/Applications 


Simple Divided Screen 
Navigation Tools 


Presentation Objects 


Unedited Multimedia News Items 


Virtual File System 


Categorized Articles 


Actual File System 


The Oracle Database 


Virtual InterProcess 
Communication Mechanism 


None 


Actual Network 


EXPANSE (see Bussey et al 1989). 



Figure 3 

Description of the Passive Information Grazing Prototype 



The research prototype of the Passive Information Grazing System provides the user with a con- 
tinuous stream of multimedia information through a simple interface. Before reaching the user 
the information passes through a filter eliminating articles that according to a personalized user 
profile, are of no interest to the user. Figure 3 shows a brief overview of the system from the 
perspective of the reference model. 



INTERSECTING DIMENSIONS AND STANDARDIZATION ISSUES. 

Hypermedia systems require a very rich infrastructure. Even though they may be viewed as 
mere application programs, they put a severe strain on existing computational and communica- 
tion resources. They push today's technologies to their limits. Therefore, when it comes to stan- 
dardization it may be ill advised to consider Hypermedia as a standalone application and not as a 
system that is closely coupled with the development of its infrastructure. For example, from the 
viewpoint of resources, the actual performance and capabilities of the system are affected by 
resources available at each of the levels described in Figure 1. Parameters such as network relia- 
bility and speed, information storage capacity, CPU "horse power", and tenninal capabilities 

X Window System is a trademark of IvHT. 



-141- 



may play a major role in defining the future shape of Hypermedia applications. 

Keeping the Hypermedia dependencies on its infrastmciui^e in mind, we will proceed to discuss 
Hypermedia and its standardization from the view point of the Hypermedia application writer, 
According to the reference model presented in Figure 1, the application writer is equipped with 
terminal independent and file system independent authoring tools. In our framework, the appli- 
cation writer is responsible for producing the Presentation Objects, and the User Interface. The 
Presentation Objects are the key elements of the system. A collection of them resides in the vir- 
tual file system, and they are displayed on the interface. Aspects of their structure are given in 
Figure 4. 



Object Description: 
links 
attributes 
authorization 
displaying methods 

Object Presentation: 
envelope 
body 



Figure 4 

The Structure of Presentation Objects. 

It is important to note that in the context of the current discussion, the Presentation Objects pro- 
vide a way to cai"ve-up meaningful presentable pieces of multimedia information. This is due to 
the fact that the Presentation Objects contain sufficient specification to guarantee that they can 
be displayed, classified, stored, retrieved, and filtered in a global Hypennedia system. Also, 
they essentially represent an "Object Oriented Approach" to Hypermedia information represen- 
tation and management. 

We view Presentation Objects as consisting of two main parts ~ the Description part and the 
Presentation part. The Description part contains the links that the object has to other objects, 
attribute of the object such as its size and the resources it needs, information about authorization 
and authoring tools, and methods to display it. The Presentation part of the object contains the 
envelope and the body. The envelope contains preview information about the body of the 
object, e.g. title, abstract, video clip etc. The body is (a pointer to) the content of the object. 

The level of the dialogue captures user interface and session management issues. Some of its 
functionality is given in Figure 5. 



-142- 



Current Status 
Available Objects 
Open Objects 

Navigation Tools: 

within object navigation 
between objects navigation 

Authoring Tools 
Displaying Tools 



Figure 5 

The Level of the Dialogue (Applications) 



CONCLUSIONS 

We are now in a position to consider our central problem here: What do we need to standardize 
in order to guarantee information sharing in Hypermedia systems that operate over a global 
heterogeneous information network? 

The standardization of the virtual terminal, the virtual file system, and the virtual interprocesses 
communication mechanism should come first. These standards will guarantee that any applica- 
tion can run on the standard virtual terminal irrespective of the terminal and the actual file sys- 
tem used, and that any network can be used for communication given that it can emulate the vir- 
tual network. Regarding the Hjrpemiedia components, the Presentation Objects should be the 
next in line for standardization. However, as stated in the opening section, since at the present 
time we still cannot assess the potential multimedia capabilities of the future we must wait for 
the above standards before we consider freezing the form of the Presentation Objects and their 
database. 

If we now look at the situation where all the levels in Figure 1 are a standard except the applica- 
tion level we immediately realize that there is no point in standardizing it. The fact that the lev- 
els above and below it are a standard impose a strong enough constraint that produces a standard 
set of tools to build the software at that level. This approach sets the functionality of Hyper- 
media but not its "look and feel". We believe that at this point it is still inappropriate to stand- 
ardize "look and feel" of Hypermedia because not enough is known about the relationship 



-143- 



between the users' cognitive skills and personal preferences and the benefits that Hypermedia 
has to offer to them. Therefore, at this point, a standard user interface may defeat the purpose of 
user-friendliness and may make personalized access to information impossible. 



BIBLIOGRAPHY 

Bussey H., Edigo C. Kaplan A. Rohall S. and Yuan R. (1989). Service Architecture, Prototype 
Description, and Network Implications of a Personalized Information Grazing Service. Submit- 
ted to Infocom '90. 

Judd T.H. and Cruz G.C (1989). Customized Electronic Magazines - Electronic Publishing for 
Information Grazing. Advanced Printing of Paper Summaries, Electronic Imaging '89, Vol. 1, 
pp. 504 - 509. 



-144- 



A Formal Model of Hypertext* 



Danny B. Lange 



Briiel & Kjaer Industri A/S^ 
DK - 2850 Naerum, Denmark 
Tel: +45 42 80 05 00 
email: danny.lange@bk.dk 



Department of Computing Science 
Technical University of Denmark 
DK - 2800 Lyngby, Denmark 



.t 



January 22, 1990 



Abstract 



In this paper a formal specification of an abstract model of hypertext is presented. 
The Vienna Development Method (VDM) is used in this specification. Experiences 
with a prototype hypertext system and studies of other existing hypertext systems are 
captm-ed in this formal specification. Basically datamodel of hypertext is suggested. In 
this model three main abstract data types of hypertext are formally defined: nodes, 
networks and structures. The abstract data types are applied to the concepts of object- 
oriented databases and a "hyp>erbase" is defined. 

1 Introduction 

Hypertext is becoming a w^ell-known technique for information representation and management. Differ- 
ent research projects show that hypertext has many potential applications that are just beginning to 
be explored: textbooks, dictionaries, encyclopedias and software engineering [Hypertext 1989]. At the 
Hypertext'89 Conference a wide range of hypertext products were presented. They all covered many dif- 
ferent aspects of hypertext. But, they had one thing in common. When it comes to means of interchange 
and communication between these systems they are all doomed to fail. 

In this jungle of different systems, publishers of hypertexts must worry about portability of their works 
between different hypertext systems to ensure that they don't depend to much upon the success of one 
system. The users of hypertext systems must worry about the supply of hypertexts or use of hypertext 
organization of long-lived project documentation stored in a specific hypertext system, making the data 
inaccessible for other (hypertext) systems. 

Steps toward interchange and communication between open hypertext systems must be based on 
formal and abstract models of hypertext to which all existing and hopefully future systems can be 
related. In the last few years an increasing number of papers on hypertext and its application has 
been published. Only a very small part of this work has been concerned with the formal treatment 
of hypertext. There is clearly a need for a more formal approach to hypertext since one can claim 
that hypertext is driven by user interface and implementation considerations [Halasz &; Conklin 1989]. 
Looking through the Hypertext'89 Proceedings [Hypertext 1989] one will find dissapointing few pa- 
pers on the more formal and abstract aspects of hypertext. However, attempts to present more for- 
mal models of hypertext have appeared [Delisle k Schwartz 1987] [Garg 1988] [Stotts k Furuta 1989] 
[Consens &: Mendelzon 1989]. This paper presents a formal model of hypertext, using the Vienna Devel- 
opment Method (VDM) [Bj0rner k Jones 1982] [Jones 1986]. VDM supports the top-down developmant 

'A version of this paper emphasizing a formal specification methodology and with different technical details, but in- 
evitably overlapping in the datamodel facet with the present paper, is being presented at VDM '90 and pubUshed in the 
conference proceedings by kind permission of the Programme Comittee and the editors. 

^Author's Present Address 

'a part of the work has taken place at the Technical University of Denmark 



-145- 




Figure 1; A Snapshot of the Prototype 



of software systems specified in a notion suitable for formal verifikation. The specifications are based on 
a datamodel using high-level types as set, list, map and cartesian products. Function specification are 
written in predicate logic, using pre- conditions stating the properties that the inputs must satisfy, and 
post- conditions which states the relationship of inputs to outputs. 

At Briiel & Kjaer^ we have developed a prototype of a hypertext system. The prototype was developed 
on a SUN3 workstation' using an expert system shell called ART^. The prototype was written partly 
in ART'S rule-based language and Common Lisp [Steele 1984] using a window based user interface, see 
figure 1. The prototype has fulfilled several aims. First it has given the developers a feeling of what 
hypertext is all about, by working with the prototype. Secondly the ideas of hypertext has easily been 
communicated to non-experts and potential users. 

Our experiences with this prototype and studies of hypertext systems as HyperCard, Hyperties, Nep- 
tune, KMS, Nodecards, etc. is captured in the formal specification presented in section 2 and section 
3 in this paper. In section 2 the datamodel of hypertext is presented by domain equations giving a 
formal definition of the primitives of hypertext, introducing the three main concepts: nodes, links and 
structures. In section 3 the datamodel is extended with a set of operations in an object-oriented way, 
defining abstract datatypes of nodes, links and structures. Our experiences with this formal model and 
future work are discussed and concluded in section 4. Detailed pre-/post- specifications of the specified 
operations can be found in appendix A. 

2 Developing a Basic Datamodel of Hypertext 

The hypertext datamodel has evolved on basis of the experience with our prototype and our general 
knowledge to the domain. The model will include the concept of nodes and their interior, links between 
nodes and between fields and buttons inside the nodes. Different kinds of links are described: N-ary 
links, second order links and active links. Additionally the idea of having structures organizing nodes in 
e.g. hierarchies, is introduced. 

In the following a datamodel of hypertext is developed through stepwise refinement. Initially the 
meaning of hypertext is defined as a database that has active cross-references, allowing the user to have 
nonsequential access to a text thereby making the reading process nonlinear. A hypertext can be modelled 
as a set of nodes and a collection of hnks where the nodes are documents and the links are cross-references. 

^Briiel & Kjaer Industri is a company that designs and manufactiires high- precision electronic measuring instruments. 

^Sun Workstation is a registered trademark of Sun Microsystems, Inc. 

''art (Automated Reasoning Tool) is a registered trademark of Inference Corporation. 



-146- 



Figure 2: Example of linked nodes 



1.0 Hypertext :: Nodes x Links 

2.0 Nodes = "chunks of information" 

3.0 Links = "cross-references" 

2.1 Nodes - Units of Information 

An information fragment in a hypertext is called a node. Thus, hypertext is made up of a collection of 
distinct named information fragments. Conceptually this information fragment usually describes a single 
concept or topic. The names may be assigned explicitly by the user or they can be assigned automatically. 

In some hypertexts it might be necessary to divide the nodes into several different types: document, 
illustration, annotation, etc. Thus, it must be possible to add attributes and attribute values to nodes. 

4.0 Nodes = Nid frt (Node x Attributes) 
5.0 Node :: "information" 
6.0 Nid :: TOKEN 

2.2 Links - the Glue that Holds Hypertext Together 

A connection between tw^o nodes is called a link. When a link is activated, say by a mouse click, one 
can jump to the node the link points to. A hypertext network is made up of a collection of uniquely 
named links. Links can be used to transfer the reader to an new topic, provide access to an annotation 
or footnote, show a reference and so on. Conceptually a link is directed, i.e. it points from one node to 
another, having an origin called the anchor and an end point called the destination. However this does 
not mean that links are unidirectional, that is, the passage is not only one-way. One can always pose the 
question: who points to me? 

In figure 2 one can see an example of a document consisting of a section, two subsections and a 
reference list. The section is. connected to its subsections through node to node links. All three items 
link to a common reference list. The section node might contain the text of the introduction to the two 
subsections, and the nodes of the subsections, contains the text of the subsections. Below the concept 
of linking is restricted to only concern connections between entire nodes. In section 2.4 the model is 
extended to include links between the contents of one node and another node. 

A hypertext system may have only one type of link or it may have several types. The link type can 
reflect the type of information it is pointing to, making it possible for the user only to view links of a 
certain type. Different types of links in a document could be references to related articles or reviewers 
annotations. To represent this variety of linktypes, they can be attributed in the same manner as for 
nodes. 



-147- 



Na.me 



Address 



Phone 



Family 



Figure 3: Example of the use of schema 



7.0 Links 

8.0 Link 

9.0 Connections 

10.0 Anchor, Destination 

11.0 Lid 



= Lid -fjt Link 

:: Connections x Attributes 

:: Anchor x Destination 

= Nid 

:: TOKEN 



An important point in hypertext is the support for collaborative work. If several people are reviewing 
and annotating the same hypertext, they all use the common network made by the author of the document. 
To this common network each individual can add a personal subnetwork reflecting their own need for 
referencing across the common network and including references for their annotations. Looking at other 
persons sub-networks, one can inspect their annotations, possibly realizing that further comments on 
specific topics are needless, thus saving time in a review process. This does not remove the need for 
attributed links. One may still need to add individual information to the link, like the time when it was 
created, why it was created, etc. 



12.0 Networks = Nwid frt (Links x Attributes) 
13.0 Nwid :: TOKEN 



2.3 Slots - the Interior of the Node 

Conceptually the node can cover a wide range of applications, i.e. representing a chapter or section in a 
document, function definitions in the source text of programs, organizing information on notecards, etc. 
Obviously there is a need for a substructure in the interior of the node. 

A slot is a kind of template for the contents of the node. It can be compared to the record datatype in 
programming languages. A node has a collection of unique named slots, each having some kind of textual 
content. An example of the use of schema in a node is shown in figure 3. In this example information on 
individuals is organized in an archive. For each person exists one basic "card" carrying a specific set of 
information: name, address, phone and family. "Cards" can be annotated and one can make references 
between the "cards". In the family slot, one can mention the spouse and make a link to his/her "card". 
In our model theser "cards" are equal to the node. 

Slots can be connection points for links. As anchors and destinations they are identified by the node 
in which they are embedded and their name. 



14.0 Node = Slid ^ Slot 

15.0 Slot :: String x Attributes 

16.0 Stnng :: CHAR* 

17.0 Anchor, Destination = ... | (Nid x Slid) 

18.0 Slid :: TOKEN 



-148- 



Figure 4: Example of buttons 



2.4 Buttons and Fields - the Referential Mechanism 

In this section buttons and fields are introduced. They are the fundamental components of the referential 
mechanism, one of the most powerful properties of hypertext. Links connecting entire nodes and slots 
have already been introduced. Now the concept of hnking is extended to cover source and destination 
points inside the nodes. Pragmatically this covers the referential use of links in a hypertext. 

A handle is a part of the text inside the slot to which a hnk can be attached. This makes it possible 
to establish connections between the contents of one node and another node. A handle is defined as a 
consecutive sequence of characters in the textual contents of the slot. More precisely by its character 
position in the text and the span in numbers of characters. 

When a link is anchored to a handle, that is, there is an outgoing link from a handel, the text span 
specified by the handle is called a button. In figure 4 it is shown that one can get from an actual reference 
in the text to the reference list. 

Fields are defined exactly in the same way cis the buttons are. We have chosen to distinguish between 
these two of purely conceptual reasons, thus having fields as one of the possible end-points of hnks. 

The domain of connections is extended to include buttons and fields. From a connections point of 
view, a button or field is identified by the node and slot in which it is embedded and its handle in that 
slot. 



19.0 


Slot :: 


Siring x Handles x Attributes 


20.0 


Handles = 


Hid j!t Region 


21.0 


Region :: 


Position X Length 


22.0 


Position, Length :: 


No 


23.0 


Anchor = 


... 1 Button 


24.0 


Destination = 


... 1 Field 


25.0 


Button, Fields :: 


(Ntd X Slid X Hid) 



To continue the example, the use of fields makes it possible to follow a reference not only to the 
reference list but to a certain entry in this reference Hst, see figure 5. Depending on the user-interface 
the entry, i.e. the field, is accentuated. 

2.5 More on Links - N-ary Links, 2nd Order Links and Active Links 

So far only binary links has been treated. Binary hnks are characterized by one link anchor and one 
destination point. They match the concept of navigating in a hypertext very well. That is, if one has an 
end-point of a link, there is only one way to go, if one choses to follow the link. 

For structural reasons it may be more appropriate to consider a more general concept of links. N-ary 
links have one or more link anchors and one or more destination points. In the model this means that 
a set of link anchors and destination points are bound to the same link. An example of N-aiy links is 
shown in figure 6. In this example three sections in a document refer to a certain article. Following 
the links, one might first be directed to an entry in an annotated reference list, for reading an abstract, 
and then to the article itself. In this way the concept of 7V-ary links forms the basis of following links 



-149- 



in several steps, that is being directed to a short description of the destination before actually arriving 
there. 



26.0 Connections :: Ancho r-set x DesUnation -set 

Nodes, slots and fields have been discussed as destination points for links. Links pointing at links, 
called 2nd order links, can be used to point at a collection of connections. It might reflect that a hnk 
itself is of special interest, and that the reader after being guided to the link, can chose to study the 
anchor or destination of the Imk. Links are identified as connection points by name of the network in 
which they are embedded, and their own name. 

27.0 Anchor, Desiinaiion = ... | (Nwid x Lid) 

Active links are links that have anchors or destinations that are function denotations. That is, instead 
of having hnks pointing at fragments of text they contain a function. This function is to be interpreted 
when one is following the link. This kind of a link can be used to generate a view of the data it is anchored 
to. That could be the generation of a graphical representation of the data each time one is following 
the link. A function signature is added to the domain of anchors and destinations. The domains of the 
arguments and the results of the function are not specified in any further detail. 

28.0 Anchor, Destination — ... \ Argument^set ^ Resul t-set 
29.0 Argument, Result =: ... 

2.6 Structures - the Organizers of Hypertext 

The hypertext in figure 2 represents the most simple organisation of a hypertext. This example of a 
hypertext is a set nodes connected by links. A hierarchy of nodes in a hypertext is another primitive 
example of organising an hypertext. It is a way of organizing information into meaningfull parts e.g. 
documents into sections and subsections. Figure 7 shows such a hierarchy of sections and subsections in 
a document. The user is usually free to define information structures in traditionally hypertext systems 
as they are needed. But, the novice user sometimes may require guidance by the hypertext itself, or one 
may find ad hoc organisation of hypertexts potentially dangerous. The problem can be solved by using 
structures. 

Structures should prescribe an organization of nodes and networks. They can conceptually be com- 
pared to the domain equations in VDM, introducing sets, sequences, maps and the possibility of recursive 
definitions, e.g. tree data structures. The structures can form a basis for an algebra for structured hy- 
pertext documents [Giiting et al.]. 

The use of the set-structure has already been demonstrated and fits well into card-like hypertexts. 
The map-structure can extend this unordered collection of cards with a facility of direct access by user 
defined names. Sequences can be used to express interrelationships between nodes as the sequence in 




Figure 5: Example of Fields 



-150- 



which they should be visited, e.g. chapters in a book. Defining these structures recursively, makes it 
possible to make tree structures of nodes. 

It should be emphasized that it is not the nodes and networks themselves that are organized in these 
structures. The structures contains only the names of the nodes and networks. Hence it possible to reuse 
nodes and networks in several structures. E.g. one can think of a section or figure appearing in more 
than one book, and thus in several structures. 

Structures can be interpretated by filters, to make hnear representations of the hypertext, e.g. on 
paper. A tree structure of a book should intuitively be interpreted by a filter in a top-down left-to-right 
manner, so that chapter one and the subsections of this chapter are written out before chapter two and 
so on. 

Structures are uniquely identified by their name. Each structure is characterized by having a col- 
lection of substructures, each organizing destinations into sets, sequences or maps. The substructures 
themselves have unique identities and can be destinations, thus making it possible to build more compli- 
cated structures. A structure has a root that can identify one of the substructures as being the root of 
the structure. 



30 


0 


Structures 


— Sid Tft (Structure x Attributes) 


31 


0 


Structure 


= Subsid yrt Substructure 


32 


0 


Substructure 


= Substruc X Attributes 


33 


0 


Substruc 


= Set 1 Seq \ Map 


34 


0 


Set 


— Desttnation-set 


35 


0 


Seq 


— Destination* 


36 


0 


Map 


= TOKENiTt Destination 


37 


0 


Anchor, Destination 


= ... 1 Sid 1 (Sid X Subsid) 


38 


0 


Sid, Subsid 


:: TOKEN 



2.7 The Attributes 

Attributes are basically a mapping between names of attributes and their values. The names of the 
attributes are user defined. The values of the attributes can be of a simple text or numerical type, 
but one can also expect structured types as known from the attributes of attribute grammars. Among 
attributes that should be mentioned are version numbers, time for creation, access rights, protection, etc. 

39.0 Attributes = Attribute jyt Value 
40.0 Attribute :: TOKEN 
41.0 Value :: ... 



2.8 The Hypertexts - Bringing It All Together 

Basically the developed datamodel says that a hypertext is a collection of nodes and one or more networks 
connecting the nodes and a structure describing the organization of the parts that forms the hypertext. 




Figure 6: Example of N-ary links 



-151- 



Figure 7: Example of a hierarchy 



The networks represent the referential links, that is the explicit links connecting two or more parts of 
the hypertext. The structures are organizing the nodes and the networks. One can say that there is 
a dualism between networks and structures in that structures represent a kind of organizational links 
between nodes in a hypertext. 

In this way one can represent several hypertext applications in a collection of nodes, simply by letting 
the actual hypertext application apply a certain network and a certain structure to the nodes. Then 
actual buttons in a node are first resolved by the hypertext application when one or more networks are 
applied to it and the node will show different sets of buttons depending on the applied networks. Finally 
a hypertext is defined as: 

42.0 Hypertext :: Nodes x Networks x Structures 

This observation leads to the object-oriented approach to a model, defining the hyperbase in terms 
of abstract datatypes, as presented in the following section. 

3 An Object-Oriented Model 

Having seen the basic datamodel of hypertext it clearly seems to be an good idea to follow an object- 
oriented approach in the specification of the semantic functions. Nodes, networks, and structures should 
be defined as abstract datatypes. The domains of each of these datatypes has already been described in 
the previous section. 

In the following a simple model of an object-oriented database is presented. Based upon this model 
the operations of the abstract datatypes, as introduced by the datamodel in the previous section, is 
formally specified. 

3.1 An Informal Model of an Object-Oriented Database 

The class of an object is the abstract data type of the objects. Thus an object may be thought of as 
an instance of a particular class. The class defines the operations that can be applied to the object by 
an apphcation. A class defines the set of operations applicable to all instances of that class in terms of 
names of operations and types of formal arguments and results. An implementation of a class provides a 
set of operation procedures implementing the set of operations defined by the class. The implementation 
encapsulates the data representation and the algorithms that are used to perform the operations. The data 
represention of an object is a collection of data that makes up the state of the object. The state is managed 
by the implementation and is only accessible by means of the operation procedures [Crawley 1986]. 

Below the basic domain of an object-oriented database is modelled as a collection of instantiated 
objects each having an unique identity. An instantiated object has a state that can be changed through 
the set of class operations. The domain of the state and the set of class operations are defined by the 
type definition of the class. 



-152- 



Hyperbase 




Nodes Networks Structures 




Figure 8: The Clciss Hierarchy 



43.0 
44.0 
45.0 
46.0 
47.0 
48.0 



Objecibase 

Object 

State 

Opes 

Ope 

Args, Res 



Objid Jff Object 
State X Opes 

Opeid -nt Ope 
Args ^ State ^ 



(State X Res) 



3.2 An Object-Oriented Hyperbase 

Now the domain of hyperbases are apphed to the concepts of object-oriented databases. The hyperbase 
covers basic operations on instances as the creation of new instances, basic object version management 
and object access control. 

An object-oriented hyperbase is in this way defined as a collection of uniquely named instances of 
three object types. Each instance has a state which type depends on the type of the object. The three 
applicable state type are node, network and structure, as defined in the datamodel. A set of operations 
are defined for each type. Furthermore each instance has a set of predecessors and successors, identifying 
the neighbours of the instance in the version chain. 



49.0 


HyperBase 


= Objid Jff Object 




50.0 


Object 


:: State x Operations x Attributes x 


Succ-set X Pred-set 


51.0 


State 


= Node 1 Links | Structure 




52.0 


Objid 


= Nid 1 Nwtd 1 Sid 




53.0 


Operations 


= Opeid Tft Operation 




54.0 


Operation 


= Araument-set ^ State ^ (State x 


Result-set) 


55.0 


Opeid 


:: TOKEN 





3.2.1 Fundamental Operations 

The CreatelnstanceOf operation can make instances of the subclasses, that is, it can make node, network 
and structural objects, returning the unique names of these objects. These instances can be destroyed by 
the Destroylnstance operation. The collection of identities of instances of a given class can be collected 
by the SetOflnstances operation. 



56.0 ObjectClass = Nodes | Networks | Structures 



-153- 



57.0 type ; CreatelnstanceOf : ObjectClass ^ Hyperhase ^ (Objid x Hyperbase) 
.1 type ; Destroy Instance : Objid ^ Hyperbase ^ Hyperbase 
.2 type; SeiOf Instances : ObjectClass ^ Hyperbase ^ Obji d-set 

3.2.2 Basic Object Version Mangagement 

This set of functions refer to the version management of the hyperbase. The CreateSuccessorOflnstance 
creates a copy of a specified object instance. The identity of the created object instance in added to 
the successor set of the specified instance, which identity on the other hand is added to the predecessor 
set of the new object instance. The predecessor and successor sets of an instance are found respectively 
by the PredecessorOflnstance and 5wccessorO//?is<ance operations. The Mer^e/nsiances operation merge 
two objects into one object. 

58.0 type .' CreateSuccessorOflnstance : Objid ^ Hyperbase ^ (HyperBase x Objid) 

.1 type ; PredecessorOflnstance : Objid ^ Hyperbase ^ Obji d-set 

.2 type .• SuccessorOflnstance : Objid ^ Hyperbase ^ Obji d-set 

.3 type ; Mergelnstances : Objid x Objid ^ Hyperbase ^ (HyperBase x Objid) 

3.2.3 Object Access Control 

The Open operation are concerned with checking the access conditions of the instance before allowing 
access to the set of operations. The close operation reset the access conditions after they have been 
altered by a previous open. One has access to the operations of the hyperbase objects through the 
OperateOnlnstance function. The identity of the object instance and the name of the operation to be 
executed is passed to this function. 

59.0 type ; Open : ... 
.1 type ; Close : ... 

.2 type ; OperateOnlnstance: Objidx Opeidx Argumen t-set ^ HyperBase^ fHyperBasex Resul t-set ) 

3.2.4 Object Attribute Operations 

AddAttribute adds an named attribute to the set of attributes of the slot. Attributes are removed by the 
RemoveAttribute operation. Values are assigned to attributes by the AssignAttribute operation. Finally 
a value of an attribute is read by using Read Attribute. 

60.0 type ; AddAttribute : (Objid x Name) ^ Node ^ Node 

.1 type ; RemoveAttribute : (Objid x Name) ^ Node ^ Node 

.2 type ; AssignAttribute : (Objid x Name x Value) ^ Node ^ Node 

.3 type ; ReadAttribute : (Objid x Name) ^ Node ^ Value 

3.3 The Three Object Classes of a Hyperbase 

The three object classes or abstract datatypes of a hyperbase represent the nodes, the networks and the 
structures. 

3.3.1 A Node Class 

The objects of the node class are having zero or more slots. The operations are divided into three groups. 
The first set of operations is grouped around the schema of the node, and the second set is grouped 
around the end-point of links: handles and regions. The final group of operations is the node attributes 
operations. 



-154- 



Slot Operations. The A ddS lot operation adds a new and empty slot to the node instance. The identity 
of the new slot is returned to the user. The RemoveSloi operation can remove a slot and its contents 
from the node. One can use the RetumSlots operation to get set of names of the slots allocated in the 
schema of a node instance. 

61.0 tx£e.- AddSlot : () ^ Node ^ (Node x Slid) 
.1 type ; RemoveSloi : Slid ^ Node ^ Node 
.2 type .- RetumSlots : () ^ Node ^ Shd-set 

Slot Browsing Operations. The contents of a specified slot can be delivered ais a string of characters 
by using SlotView. Slotlnsert is an example of an editing operation. One can use this operation for 
insertion of a string into a position in the contents of a specified slot. SloiDeleie can be used to remove 
a specified portion text of the contents of a slot. 

62.0 type ; SlotVtew : Slid ^ Node ^ STRING 

.1 type ; Slotlnsert : (Slid x STRING x Position) ^ Node ^ Node 

.2 type ; SlotDelete ; (Slid x Position x Length) ^ Node ^(Node x Hi d-set) 

Handle Operations. A handle can be added to a specified region of the contents of a slot by the 
AddHandle operation. The handle is given a unique identity which is returned to the user. One can add 
several handles to the same region, and regions can be overlapping. A handle is removed by using Remove- 
Handle. The names of the handles located in a slot are returned by ReturnPositionHandles operation, 
and the names of the handles at a specified position in a slot is returned by the ReturnPositionHandles 
operation. The region specified by a handle is returned by the GetHandle operation. 

63.0 type ; AddHandle : (Slid x Region) ^ Node — > (Node x Hid) 

.1 type ; RemoveHandle : (Slid x Hid) ^ Node ^ Node 

.2 type ; ReturnSlotHandles : Slid ^ Node ^ Hi d-set 

.3 type ; ReturnPositionHandles : (Slid x Position) ^ Node ^ Hi d-set 

A type ; GetHandle : (Slid x Hid) ^ Node ^ Region 

The Slot Attribute Operations. AddAitribute adds an named attribute to the set of attributes of 
the slot. Attributes are removed by the Remove Attribute operation. Values are assigned to attributes by 
the AssignAttribute operation. Finally a value of an attribute is read by using Read Attribute. 

64.0 type ; AddAttribute : (Slid x Name) ^ Node ^ Node 

.1 type ; RernoveAttribute : (Slid x Name) ^ Node ^ Node 

.2 type ; AssignAttribute : (Slid x Name x Value) ^ Node ^ Node 

.3 type ; ReadAttnbute : (Slid x Name) ^ Node ^ Value 

3.3.2 A Network Class 

The operations of the network class consists of six network changing operations and three querying 
operations. 

Network Changing Operations. The AddLink operation adds a new and empty Unk to the network. 
The operation gives the link a unique identity which is returned to the user. A link i removed by the 
RemoveLink operation. The anchors and destinations of the link in question, does not have to be empty. 
Anchors and destinations are added to a specified link by the two operations: Add An char and Add- 
Destination. Removing anchors or destinations are done by the RemoveAnchor and RemoveDestinaiion 
operations. 



-155- 



65.0 type ; AddLink : () ^ Links ^ (Links x Lid) 

.1 type ; RemoveLink : Lid ^ Links ^ Links 

.2 type ; AddAnchor : (Lid x Anchor) ^ Links ^ Links 

.3 type ; RemovcAnchor : (Lid x Anchor) ^ Links ^ Links 

A type ; AddDesiinaiion : (Lid x Destination) ^ Links ^ Links 

.5 type ; RemoveDestination : (Lid x Destination) ^ Links ^ Links 

Network Querying Operations. The two querying operations Having Anchor and HavingDestination 
are used to identify the links of a certain network instance, that haye the specified anchors/destination 
in common. The ReadLink operation reads the anchor and destination set of the specified hnk. 



66.0 type ; HavingAnchor : Anchor^ Links ^ Li d-set 

.1 type ; HavingDestination : Destination ^ Links ^ Li d-set 

.2 type ; ReadLink : Lid ^ Links ^ (Ancho r-set x Destinatio n-set) 

The Link Attribute Operations. AddAttribute adds an named attribute to the set of attributes 
of the specified hnk. Attributes are removed by the Remove Attribute operation. Values are assigned to 
attributes by the AssignAttribute operation. Finally a value of an attribute is read by using ReadAttribute. 

67.0 type ; AddAttribute : (Lid x Name) ^ Links ^ Links 

.1 type ; RemoveAttribute : (Lid x Name) ^ Links ^ Links 

.2 type ; AssignAttribute : (Lid x Name x Value) ^ Links ^ Links 

.3 type ; ReadAttribute : (Lid x Name) ^ Links ^ Value 

3.3.3 A Structural Class. 

The operations of a structure are divided into four groups. The first is concerned the more general 
operations on the structure, i.e. adding and removing substructures etc. The final three groups are 
concerned with the specific operations of the three types of substructures: sets, sequences and maps. 



Structure Operations A substructure can be added to the structure by using the AddSubstructure 
operation. A substructure is removed by RemoveSubstructure. The of identities of the substructures 
pointing the specified destination is returned by the HavingDestination operation. Finally, one can get 
the type of a substructure by using the GetSub structure Type operation. 

68.0 Sub structure Type = Set | SEQUENCE | Map 

69.0 type ; AddSubstructure : SubsiructureType ^ Structure ^ (Structure x Subsid) 

.1 type ; RemoveSubstructure ; Subsid ^ Structure ^ Structure 

.2 type ; HavingDestination : Destination ^ Structure ^ Subsi d-set 

.3 type ; GetSub structureType : Subsid ^ Structure ^ SubstructureType 



Set Operations The AddDestination operation adds a destination to a set of destination. A destination 
element of a set i removed by RemoveDestination. The HavingDestinationSet operation can be used 
to find out whether a specified destination is in the set. The set of destinations is returned by the 
GeiDestinationSet operation. One get the number of elements in the set by using the GetCardinality 
operation. 



70.0 type ; AddDestination : (Subsid x Destination) ^ Structure ^ Structure 

.1 type ; RemoveDestination : (Subsid x Destination) —> Structure ^ Structure 

.2 type ; HavingDestinationSet : (Subsid x Destination) ^ Structure ^ BOOL 

.3 type ; GetDestinationSet : Subsid ^ Structure ^ Destination -set 

.4 type ; GetCardinality : Subsid ^ Structure ^ No 



-156- 



Sequence Operations. One can insert a destination at the specified position in the hst by using 
the InsertDestination operation. Destinations positioned at a position greater or equal to the insertion 
point, are shifted one place. By the Remove Desiinaiion operation one can remove the destination at the 
specified position. The operation works in the opposite way of the inserting operation. The operation 
returns all the positions of the specified destination in the sequence. The destination at the specified 
position is returned by GetDesiination. GeiLengih returns the length, i.e. the number of destinations in 
the list. 

71.0 type ; InsertDestination : (Suhsid x Destination x Noj ^ Structure ^ Structure 
.1 type ; RemoveDestination : (Suhsid x Nq) Structure ^ Structure 
.2 type ; Having Destination : (Suhsid x Destination) ^ Structure \i o -set 
.3 type ; GetDesiination : (Suhsid x 'No) ^ Structure ^ Destination 
A type ; GetLength : Suhsid ^ Structure No 

Map Operations. A new named destination is added by the AddDestination operation and removed 
by the RemoveDestination. All the names of a specified destination can be found by Having Destination. 
One can get the destination identified by a given name by using the GetDesiination operation. The set 
of names bound to destinations is returned by GetDomain. 

72.0 type ; AddDestination : (Suhsid x Name x Destination) ^ Structure ^ Structure 

.1 type ; RemoveDestination ; (Suhsid x Name) ^ Structure ^ Structure 

.2 type ; Having Destination : (Suhsid x Destination) ^ Structure ^ Nam e-set 

.3 type ; GetDesiination : (Suhsid x Name) ^ Structure ^ Destination 

.4 type ; GetDomain : Suhsid ^ Structure ^ Name -set 

The Structure Attribute Operations. AddAttrihute adds an named attribute to the set of attributes 
of the structure. Attributes are removed by the Remove Aitrihuie operation. Values are assigned to 
attributes by the Assign Aitrihuie operation. Finally a value of an attribute is read by using ReadAtirihute. 

73.0 type ; AddAttrihute : (Suhsid x Name) ^ Structure ^ Structure 

.1 type ; RemoveAttrihute : (Suhsid x Name) ^ Structure ^ Structure 

.2 type ; AssignAitrihute : (Suhsid x Name x Value) ^ Structure ^ Structure 

.3 type ; ReadAtirihute : (Suhsid x Name) ^ Structure ^ Value 

4 Conclusion 

One of the major decisions in the development of this model has been to separate the presentation and 
the browsing semantics from the model, and move them to the applications design. The applications 
should only operate on the hyperbase through the specified operations and the dataobjects should not 
be aware of the applications and their semantics. By adding the aspects of persistence to this object- 
oriented model we have a model of an object-oriented database. In this way issues on distribution, 
basic version management and access control could be solved in the domain of object management 
systems. It is our intention to combine this model with the european standard on portable common 
tool environments (PCTE) [Thomas 1989]. PCTE is a standard for object-oriented bases for software 
engineering environments. 

We are currently making a prototype of a hyperbase server based on the set of specifications presented 
here. This prototype is developed in the object-oriented programming language C-j--f-. Diff'erent hypertext 
applications are being developed for this server to show feasability of the model. 

With respect to the work on hypertext standardization, this model should be related to existing 
approaches to hypertext, to seek for commonality between different approaches and to make progress 
towards a complete model. It is our opinion that a hypertext standard should be defined in terms 
of abstract datatypes, to retain a maximum of representational abstraction from the viewpoint of the 
hypertext applications. An open point in the model is the interchange mechanisms between diff'erent 



-157- 



hyperbases. The model has to be extended with some kind of protocol for the transfer of hypertexts from 
one base to another. 



References 



[Bj0rner & Jones 1982] 



Bj0rner, D., Jones, C.B. Formal Specification & Sofitvare Development. 
Prentice-Hall International 1982. 



[Consens &: Mendelzon 1989] Consens, M.P., Mendelzon, A.D. Expressing Structural Hypertext Queries 

in GraphLog. In Hypertext'89 Proceedings. Pittsburgh, Pennsylvania, USA. 
November 1989. 



[Crawley 1986] 

[Delisle k Schwartz 1987] 

[Garg 1988] 

[Giiting et al.] 

[Halasz k Conkhn 1989] 

[Hypertext 1989] 
[Jones 1986] 

[Steele 1984] 

[Stotts k Furuta 1989] 

[Thomas 1989] 



Crawley, S. An Object-Based File System for Large Scale AppHcations. In 
Software Engineering Environments, ed. Ian Sommerville. Peter Peregrinus 
Ltd., 1986. 

Delisle, N.M., Schwartz, M.D. Contexts - A Partitioning Concept for Hy- 
pertext. ACM TOOIS 5, 2, ppl68-186, 1987. 

Garg, P.K. Abstraction Mechanisms in Hypertext. Communications of the 
ACM, 31, 7, pp862-870, 1988. 

Giiting, R.H., Zicari, R., Choy, D.M. An Algebra for Structured Office 
Documents. ACM TOOIS, 7, 4, ppl23-157, 1989. 

Halasz, F., Conklin, J. Issues in the Design and Application of Hypermedia 
Systems. Tutorial at SIGCHI 89, Austin, Texas, 1989. 

Hypertext'89 Proceeding. Pittsburgh, Pennsylvania, USA. November 1989. 

Jones, C.B. Systematic Software Development Using VDM. Prentice-Hall 
International 1986 

Steele Jr., G.L. Common Lisp The Language. Digital Press, 1984. 

Stotts, P.D., Furuta, R. Petri Net Based Hypertext: Document Structure 
with Browsing Semantics. ACM TOOIS, 7, 1, pp3-29, 1989. 

Thomas, I. PCTE Interfaces: Supporting Tools in Software Engineering 
Environments. IEEE Software, 6, 6, ppl5-23, 1989. 



A Detail Specifications 

A.l An Object-Oriented Hyperbase 



74.0 type ; CreaielnsianceOf : ObjectClass ^ Hyperbase -* (Objid x Hyperbase) 

.1 \>xe- CreateInstanceOf( class, ) ^class E { NODES . NETWORKS . STRUCTURES } 

.2 post- CreatelnstanceOf (class, hyperbase) (objid, hyperbase' )) ^ 
.3 let objid G Objid \ dom hyperbase in 

.4 cases class : 

.5 Nodes — > hyperbase' —■ hyperbase U [mk- Nid(obiid) ^—>■ 

.6 mk- Obiect([], NodeOpemtions, [], {], {]], 

.7 Networks — > hyperbase' = hyperbase U [mk- Nwid( o bjid) i-+ 

.8 mk- Obiect([]. LinksOperations, [], {}, {}], 

.9 Structures — ^ hyperbase' = hyperbase U [mk- Sid(obnd) t-^ 

.10 mk- Obi€ct([], StructureOperaiions, [], {}, {}], 



-158- 



75.0 type ; Destroylnstance : Objid ^ Hyperbase ^ Hyperbase 

.1 pTe- Destroylnstancefobiid, hyperbase) ^ objid € dom hyperbase 

.2 yost- DesirovInstance(obiid. hyperbase) (hyperbase' )) ^ 

.3 hyperbase' — [id i—>- (let mk- Obieci(siaie. operations, ss, ps) — hyperbase(id) 'm 

A mk- Object(state, operations, 

.5 (objid G 55— ► (ss \ {objid}) U s^Succ(hyperbase(objid)), 

.6 T ^ 5s;, 

.7 (objid E ps— •■ (ps \ {objid}) U Sj^Pred(hyperbase(objid)), 

.8 T ~.p.s;;;] 

76.0 type .- SetOflnstances : ObjectClass Hyperbase ^ Obji d-sei 

.1 pTe- SetOfInstances(class. ) ^ c/ass G { Nodes , Networks . Structures ) 

.2 Dost- SetOfInstances( class, hyperbase) (objids)) ^ 
.3 cases c/ass ; 

.4 Nodes — > objtds ~ {objid \ (\f objid G dom hyperbase )(is-Node( objid)) } 

.5 Networks — > objids — {objtd \ (M objid G dom hyperbase) fis- Links ( objid)) ] 

.6 Stru CTURES — > objids — {objid I ('V objid G dom hyperbase) f\s-StructuT'es( ob^id)) } 



A. 1.1 Basic Object Version Mangagement 

77.0 type .' CreateSuccessorOflnstance : Objid ^ Hyperbase ^ (HyperBase x Objid) 

.1 pTe- CreateSuccessorOfInstance( objid, hyperbase) ^ o6jerf G dom hyperbase 

.2 x)ost- CreateSuccessorOfInstance(obiid, hyperbase)(hyperbase' , objid')) ^ 
.3 let objid'E Objid \ dom hyperbase in 

.4 let mk- Object(state, operations, attrs, ss, ps) — hyperbase (objid) in 

.5 hyperbase' =hyperbase+[objidi- *mk- Object(state, operations, attrs, ss U {o6ji(f'}, psj] 

.6 U [o6n(/^'-^ mk- 0<>?ec<(^s<a<e, operations, attrs, {}, {objid})] 

78.0 type .' PredecessorOf Instance : Objid ^ Hyperbase ^ Obji d-set 

.1 i>re- PredecessorOfInstance(objid, hyperbase) ^ o6jzrf G dom hyperbase 

.2 \)ost- PredecessorOfInstance (objtd, hyperbase) (objids) ^ objids — s^Pred(hyperbase(obid)) 



79.0 type .' SuccessorOflnstance : Objid ^ Hyperbase ^ Obji d-set 
.1 v>xe- SuccessorOfInstance() ^ oftjic? G dom hyperbase 

.2 x>ost- SuccessorOfInstance(objid, hyperbase) (objids) ^ objids — s^Succ(hyperbase(obid)) 



80.0 type ; Mergelnstances : ... 



A. 1.2 Object Access Control 



81.0 type ; Open : ... 



82.0 type ; Close : ... 



83.0 type ; OperaieOnlnstance : ObjidxOpeidx Argumeni^set^ HyperBase^ (HyperBasexResnlt^set) 

.1 pTe- OperateOnInstance(objid, opeid, , hyperbase) ^ 

.2 oojirf G dom hyperbase A opeirf G dom s- Operations(hvperbase( objid)) 

.3 post- OperateOnlnstance (objtd, opeid, as, hyperbase) (hyperbase' , rs') ^ 
.4 let mk- 06?ec^/'sfa<e, operations, attrs, ss, ps) — hyperbase(objid) in 

.5 let (state', rs') — operations(opeid)(as, state) in 

.6 (state'::/: nil — ► 

.7 hyperbase' = hyperbase + [objid >-* mk- Object(state' , operations, attrs, ss, ps)], 

.8 s/a<e'= nil -* hyperbase' = hyperbase) 



-159- 



Object Attribute Operations. 



84.0 type ; AddAUribuie : ... 

85.0 type : RemoveAUribute : ... 

86.0 type ; AssignAUribuie : ... 

87.0 type ; ReadAUribute : ... 



A. 2 The Three Object Classes of a Hyperbase 
A. 2.1 A Node Class 
Schema Operations. 



88.0 type; AddSlot : () ^ Node ^ (Node x Slid) 

.1 pxe-AddSloi() ^ T 

.2 v>ost- AddSloifnode)( node ' . slid) ^ 

.3 let shd G Slid \ dom node in node' = node U [slid mk- S I otf< >, [], [])] 



89.0 txEe; RemoveSloi : Slid ^ Node ^ Node 

.1 v>Te- RemoveSlot(slid, node) ^ slid € dom node 

.2 v>ost- RemoveSloi f slid, node)(node' ) ^ node'— node \ {slid} 

90.0 type; RtturnSlois : () ^ Node ^ Shd-set 

.1 x>Te- ReiurnSloisQ ^ T 

.2 jiost- ReturnSloisf node)( slids) ^ s/irfs — dom node 



Slot Browsing Operations. 

91.0 type ; SlolView : Slid ^ Node ^ String 

.1 2I^SlotView(slid, node) ^ s/z'rf E dom ?).orfe 

.2 yost- Sloi Viewfslid. node)(texi) ^ 

.3 let mk- Slot( string, , ) — node(slid) in text — string 

92.0 type ; Slotlnsert : (Slid x String x Position) ^ Node ^ Node 

.1 X)ve- SloiInsert(slid. , position, node) ^ 

.2 shd G dom noc^e A Het mk- 5/o^fs^r, , ) = node(slid) in 0 < position < len str ) 

.3 x>ost- Slotlnsert (slid, s, position, node) (node' ) ^ 

.4 ( let mk- ^/o^f^feart handles, attrs) = node(slid), 

.5 mk- Slot (text ' . handles', attrs') — node' (slid) in 

.6 text' = < text[i] \ 0 < i < position> ^ s " < iext[i] \ position < i < len text > A 

.7 ('V Ait/ G dom handles) (let (^p, — handles(hid), (p', I') = handles' (hid) in 

.8 p + I < position p' = p A I' = I, 

.9 p < position >p + l-^p'=pAl' = l+ length, 

.10 position > p -* p' = p + length A I' = I 



-160- 



93.0 type ; SlotDelete : (Slid x Position x Length) ^ Node ^(Node x Hi d-set) 

.1 vie- Slot Delete (slid, position, , node) ^ 

.2 slid G dom node A 

.3 (let mk- Slot(sir, , ) — node(slid) m 

.4 ^? < position < len 5^r A position + length < len sirj 

.5 x)ost- SlotDelete(slid. position, length, node) (node', hids) ^ 

.6 (\ei mk- Slot (text, handles, attrs) — node(slid), 

.7 mk- Slot(text' , handles', attrs) — node' (slid) m 

.8 text' = <text[i] \ 0 < i < positio> ' <text[i] \ position + length < i < ]en text> A 

.9 hids = {hid \ (\/ hid G dom handles) (let (p, I) = handles(hid) in 

.10 position < p A position + length > p + I)} )) A 

.11 dom handles' — dom handles \ hids A 

.12 position < p A position -f length < p ^ p' — p - position A V = I, 

.13 position < p A position + length < p+l —* p' = p-positionAl' =l-(position+length-p), 

.14 p < position A position + length < p+l — <■ p' = p A I' = I - length, 

.15 p < position A p+l < position + length — ► p' = p A /'— / - (p+l - position), 

.16 p+l < position — p' — p A V = I 

Handle Operations. 

94.0 type .- AddHandle : (Slid x Region) ^ Node ^ (Node x Hid) 

.1 VTe- AddHandle(slid. mk- ReQion( pos, length), node) ^ 

.2 slid G dom node A ( let mk- Slot(str, , ) = node(slid) in pos+length < ]en str ) 

.3 post- AddHandle(slid. region, node)(node' , hid) ^ 

.4 let mk- Slot(text. handles, attrs) = node(slid), hid G Hid \ dom handles in 

.5 node' = node + [slid i—<- mk- Slot(text, handles U [hid region], attrs)] 

95.0 type ; RemoveHandle : (Slid x Hid) ^ Node ^ Node 

.1 x)xe- RemoveHandle(slid, hid, node) ^ 

.2 s/zrf G dom node A ( \et mk- Slot ( ,handles, ) — node(slid) in hid G dom handles ) 

.3 post- RemoveHandle (slid, hid, node)(node' ) ^ 

.4 let mk- Slot(text, handles, attrs) = node(slid) m 

.5 node' = node + [slid h- >■ mk- Slot(text, handles \ {hid'], attrs)] 

96.0 type ; ReturnSlotHandles : Slid ^ Node ^ Hid-set 

.1 pxe- ReturnSlotHandles(slid, node) ^ slid G dom not/e 

.2 post- ReturnSlotHandles( slid, node) (hids) ^ hids — dom s-Handles(node(slid)) 



97.0 type ; ReturnPositionHandles : (Slid x Position) ^ Node ^ Hi d-set 

.1 x)Te- ReturnPositionHandles (slid, position, node) ^ 

.2 s/zrf G dom node A ( let mk- Slot(str, , ) = node(slid) in position < len str ) 

.3 post- ReturnPositionHandles( . position) (hids) ^ 
.4 let mk- 5/0/ . handles, ) = n ode (slid) 'm 

.5 /iz(/s — {Airf G dom handles \ ( let mk- Region (p, I) — handles(hid) in 

.6 p < position < p+l)} 

98.0 type ; GetHandle : (Slid x ^ iVo(/e ^ Region 

.1 pxe- GetHandle(slid, hid, node) ^ s/zrf G dom norfe A hid G dom s-Handles(ndoe(slid)) 

.2 post- GetHandle(slid, hid, node)(region) ^ 

.3 let mk- 5/c'</^ , handles, ) — node(slid) In region — handles(hid) 



The Slot Attribute Operations. 
99.0 type ; AddAttrihute : ... 



-161- 



100.0 type ; RemoveAttribute 



101.0 type ; AssignAttribuie : ... 
102.0 type ; ReadAitrihuie : ... 
A. 2. 2 A Network Class 



Network Changing Operations. 

103.0 type .- AddLink : () ^ Links ^ ( Links x Lid) 

.1 vie-AddLinkf) ^ T 

.2 Most- AddLink(links) (links' , lid') ^ 

.3 let lid'£ Lid \ dom links in links' — links U [lid't-^ rnk- Link fmk- Connections({ },{} ),[])] 



104.0 type ; RemoveLink : Lid ^ Links ^ Links 

.1 V)Te- RemoveLink(lid, links) ^ lid G dom links 

.2 x>osi- RemoveLink(lid, links) (links' ) ^ links'— links \ {lid} 

105.0 type ; AddAnchor : (Lid x Anchor) ^ Links ^ Links 

.1 pTe- AddAnchor(lid, , links) ^ lid G dom links 

.2 post- AddAnchor(lid, anchor, links) (links' ) ^ 
.3 let mk- Link (mk- Connections(as, ds), aitrs) — links(lid) m 

.4 links' = links -h [lid i— + mk- Link (m\i- Connections(as U {ancAor}, ds), aitrs)] 

106.0 type ; RemoveAnchor : (Lid x Anchor) ^ Links ^ Links 

.1 vie- Remove Anchor (lid, anchor, links) ^ 

.2 G dom /mA;s A ( let mk- Connections( as, ) = links(lid) in anchor €. as ) 

.3 Dost- Remove Anchor(lid, anchor, links) (links' ) ^ 

.4 let mk- Link (mk- Conneciionsfas, ds), aitrs) — links (lid) m 

.5 links'— links -f i— > mk- i/f»A:( ink- Cow»ec<?ong/^a5 \ {anc/ior}, rfs^, a</rs^] 

107.0 type ; AddDestinaiion : (Lid x Destination) ^ Links ^ Links 

.1 i>xe- AddDestination(lid, destination, links) ^ /z'rf G dom links 

.2 post- AddDestinaiion(lid, destination, links) (links' ) ^ 
.3 let mk- LmA:( mk- Coranec/zow5(^a5, ds), aitrs) = links(lid) m 

.4 links' — links + [lid i-+ mk- Xmfc( ^mk- Connections( as, ds U {destination}), attrs)] 

108.0 type ; RemoveD esiination : (Lid x Destination) ^ Links ^ Links 

• 1 pre- RemoveDesiination(lid, destination, links) (links ' ) ^ 

.2 G dom links A ( let mk- Connections( , ds ) — links(lid) in destination E ds ) 

.3 Dost- RemoveDestination(lid, destination, links) (links ' ) ^ 

.4 let mk- XmA:( ^mk- Connec^ion5(^as. rfs^, attrs) — links (lid) 'm 

.5 links' = links -f- [lid i—^ ink^Link(mkzConnections(as, ds \ {destination}), attrs)] 

Network Querying Operations. 

109.0 type ; LI avmg Anchor : Anchor^ Links ^ Li d-set 

.1 X)Te- HavinQAnchor() ^ T 

.2 post- Having Anchor(anchor. links)(lids) ^ 

.3 /irfs — {lid G dom /m^s | let mk- Link (mk- Connections(as. ), ) = links(lid) in anchor G as} 



-162- 



110.0 type ; Having Destination : Destination ^ Links ^ Li d-set 

.1 pre- HavinQDestinationQ ^ T 

.2 x>osi- H avinoD estination(destination. links)(lids) ^ 

.3 lids = {/zrfg dom /m^s|]et mk- ZmAr Cmk- Connec<2ons('.(isj. j = links(lid) in destination G rfs} 



111.0 type ." ReadLink : Lid ^ Links ^ (Ancho r-set x Z)estmafi07 t-set) 
.1 vixe- ReadLink(lid, links) ^ /irf G dom /m^s 

.2 x>ost- ReadLink(lid. links)(as, ds) ^ mk- ZmA:( rnk- Connec^tons^^aa. </s^, ) = links(lid) 
The Link Attribute Operations. 
112.0 type ; AddAttribuie : ... 



113.0 type ; RemoveAttribute : ... 



114.0 type ; AssignAttribute : ... 



115.0 type ; ReadAttribute : ... 



A. 2. 3 A Structural Class. 
Structure Operations 

116.0 type ; AddSubstructure : SubstructureType ^ Structure ^ (Structure x Suhsid) 

.1 DTe- AddSubstructureQ ^ T 

.2 Dost- AddSubstructure(tvpe ,structure) (structure' ,subsid) ^ 

.3 let subsid G Subsid \ dom structure in 

.4 structure' = structure U [s«6sirf i— > 

.5 mk- Substructure ( Abases <j/pe ; 

.6 Set ^ mk-Setg > j. 

.7 Sequence mk- SeQ(< > ), 

.8 Map mk-Arapf[]^ 

117.0 type ; RemoveSubstructure : Subsid ^ Structure ^ Structure 

.1 \)Te- RemoveSubstructure(subsid, structure) ^ subsid G dom structure 

.2 yost- RemoveSubstructure (subsid, structure) (structure' ) ^ structure' = structure \ {subsid} 



118.0 type ; Having Destination : Destination ^ Structure ^ Subsi d-set 

.1 pre- HavinQDestinationQ ^ T 

.2 Dost- HavinQDestination(destination, structures) (subsids) ^ 

.3 subsids — {swftsirf | ('V subsid G dom structure) 

.4 let mk- Substucture(substruc, ) — structure(subsid) in 

.5 cases substruc : 

.6 Set -* destination G s, 

.7 Sequence — ► destination G elems s, 

.8 Map -+ destination G rng s^} 



-163- 



119.0 type : GetSuhstruciureType : Suhsid ^ Structure ^ SubstructureType 

.1 T>Te- GetSubstructureTvpefsubstd, structure) ^ subsid G dom structure 

.2 post- GetSu bstructure Tvpe(subsid, structure) (type) ^ 
.3 let mk- Suhstucture(substruc, ) = structure(subsid) m 

A type = / cases substruc : 

.5 mk^SetQ Set . 

' .6 mk- SegQ ->■ Sequence , 

.7 mk- Mapf) -> Map j 

Set Operations 

120.0 type ; AddDestinatton : (Subsid x Destination) ^ Structure ^ Structure 

.1 v>xe- AddDestination(subsid, , structure)^ 
.2 subsid G dom structure A 

.3 let mk- Substructure(substruc, ) = struciures(subsid) in 'is-Set(substruc) 

A \>osi- A ddDestination( subsid, destination, structure) (structure' ) ^ 
.5 let mk- Substructure(substruc, atirs) = structure (subsid) in 

.6 structure' — structure + [subsid f-^ Tnk- Subsiructure(substrucUi destination] ,attrs)] 

121.0 type ; RemoveDesiinaiion : (Subsid x Destination) ^ Structure ^ Structure 

.1 \)xe- RemoveDestination( subsid, destination, structure) ^ 
.2 subsid G dom structure A 

.3 let mk- Substructure (substruc, ) — structures (subsid) in 

.4 \s- Set (substruc) A destination G substruc 

.5 post- RemoveDestination(subsid. destination, structure) (structure' )^ 

.6 let mk- Substructure (substruc, attrs) — structure (subsid) in 

.7 structure' — structure + [subsid i-y mk- Substructure (substruc \ {destination}, attrs)] 

122.0 type ; HavmgDestinationSet : (Subsid x Destination) ^ Structure ^ BOOL 

.1 pre- Having DestinationSet(subsid, , structure) ^ 
.2 subsid G dom structure A 

.3 let mk- Substructure (substruc, ) — structures (subsid) in is- Set(substruc) 

A x>osi- HavinqDestinationSet( subsid, destination, structure) (b) ^ 

.5 let mk- Substructure (substruc, ) — structure (subsid) in b ^ destination G substruc 

123.0 type ; GetDestinationSet : (Subsid) ^ Structure ^ Destination -set 

.1 VTe- GetDestinationSet(subsid, structure) ^ 
.2 subsid G dom structure A 

.3 let mk- Substructure (substruc, ) = structures(subsid) in is- Set(substruc) 

A yost- GetDestinationSet(subsid, structure) (ds) ^ 

.5 let mk- Substructure(substruc, ) — structure(subsid) in ds = substruc 

124.0 type ; GetCardinality : Subsid ^ Structure ^ No 

.1 VTe- GetCardinalitv(subsid, structure) ^ 
.2 subsid G dom substructure A 

.3 let SM^s/rac — s-Substruc(substructures(subsid)) in is-Set(substruc) 

A post- GetCardinalitv(subsid, structures) (cd) ^ 

.5 let mk- Substructure(substruc. ) — structure(subsid) m cd = card substruc 



-164- 



Sequence Operations. 



125.0 type ; InseriDestination : (Subsid x Destinaiton x 'No) ^ Structure ^ Structure 

.1 ])ve- InsertDestination(subsid, , index, structure) ^ 
.2 subsid G dom substructure A 

.3 let mk- Substructure(substruc, ) — structure (subsid) 'm 

A is- Seafsubsiruc) A 0 < index < [ensubstruc 

.5 x>osi- InsertDesiination(subsid. destination, index, structures) (structure' )^ 

.6 let mk- Substructure(subsiruc, atirs) — structure(subsid) \n 

.7 structure' =siructure+[subsid ^-^ m]<i- Subsirncture(<substruc\i\\0<i<index>~ 

.8 <destination > " <subsiruc[i\ \ index < i < ]en subsiruO, atirs)] 

126.0 type ." RemoveDesiination : (Subsid x No) ^ Structure ^ Structure 

.1 DTe- RemoveDestination(subsid, index, structure)^ 
.2 subsid G dom substructure A 

.3 let mk- Subsiructure(substruc, ) — structure(subsid) in 

.4 is-SeQ(substruc) A 0 < index < \ensubstruc 

.5 yost- RemoveDestinaiion(subsid. index, structure) (structure' ) ^ 

.6 let mk- Substructure (subsiruc, attrs) — structure (subsid) in 

.7 structure' =siructure+[subsid > 

.8 mk- Substructure ('<substruc[i] \ 0 < i < index > 

.9 <substruc[i] | index < i < len substruc>, atirs)] 

127.0 type ; Having Destination : (Subsid x Destination) ^ Structure —y N^-set 

.1 v>re- HavinQDesiinaiion(subsid, desiinaiion, structure) ^ 
.2 subsid E dom substructure A 

.3 let mk- Sub structure (subsiruc, ) — structure (subsid) inis- Sea (subsiruc) 

A DOst- HavinQDesiinaiion(subsid, desiinaiion, structure) (indices) ^ 

.5 let mk- Sub structure (subsiruc, ) = structure (subsid) in 

.6 indices = {i \ (i G ind subsiruc) (substruc[i]= destination)^ 

128.0 type ; GeiDestinaiion : (Subsid x No) ^ Structure ^ Destination 

.1 v>Te- GeiDestinationfsubsid, index, siruciure) ^ 
.2 subsid G dom substructure A 

.3 let mk- Subsiruciure(subsiruc, ) = siruciure (subsid) 'm 

A is^Seq(subsiruc) A 0 < index < iensubsiruc 

.5 post- GeiDestinaiion f subsid, index, siruciure) (desiinaiion) ^ 

.6 let mk- Subsiruciure(subsiruc, ) — structure (subsid) in destination = subsiruc[index] 

129.0 type .- GeiLength : (Subsid) ^ Structure ^ No 

.1 pTe- GeiLenaih(subsid, siruciure) ^ 
.2 subsid G dom substructure A 

.3 let mk- Sub siruciure (subsiruc, ) = struciure(subsid) inis- Sep (subsiruc) 

A v>ost- GeiLenothfsubsid, structure) (length) ^ 

.5 let mk- Subsiruciure(substruc, ) = structures (subsid) in length = len subsiruc 



-165- 



Map Operations. 



130.0 type ; AddDesiination : (Suhstd x Name x Destination) ^ Structure ^ Structure 

.1 TQxe- AddDestinationfsuhsid, name, , structure) ^ 

.2 subsid G dom structure A 

.3 let mk- Substructurefsubstruc, ) — structure(subsid) in 

A ' is- Map(substruc) A name ^ dom suhstruc 

.5 yost- AddDestination(subsid, name, destination, structure) (substructure ' )^ 

■6 jet mk- Sub structure (sub struc, atirs) = structure (subsid) in 

131.0 type ; RemoveDesiinaiion : (Subsid x Name) ^ Structure ^ Structure 

.1 pve- RemoveDesiination(subsid, name, structure) ^ 

.2 subsid 6 dom structure A 

.3 let mk- Substructure(substruc, ) — structure(subsid) in 

A is- Map (sub struc) A name G dom substruc 

.5 yiost- RemoveDestination(subsid,nam.e, structures) (structure' )^ 

.6 let m\i- Substructure(substruc, aitrs) — structure (subsid) in 

.7 structure' =structure+[subsid i-+ mk- Substructure (substruc \ jname}, aitrs)] 

132.0 type ; Having Destination : (Subsid x Destination) ^ Structure ^ Nam e-set 

•1 VTe- Havin(iDestination(subsid, , structure)^ 

.2 subsid £ dom structure A 

.3 let mk- Substructure(substruc, ) — structure(subsid) in is-Map (substruc) 

.4 i>ost- Havin(iDesiination(subsid, destination, structure) (names) ^ 

.5 let mk- Substructure (substruc, attrs) = structure (subsid) in 

.6 names — {name \ (name £ dom substruc) (substruc(name) — rfes^maiion^} 



133.0 type." GetDestinalion : (Subsid x Name) ^ Structure ^ Destination 

.1 \)i(t- GeiDestinaiion(subsid, name, structure)^ 
.2 subsid £ dom structure A 

.3 let mk- Substruciure(substruc, ) — siructure(subsid) in i§^Map(substruc) 

.4 post- GetDesiinaiion(subsid, name, structures) (destination) ^ 

.5 let mk- Sub structure (sub struc, attrs) — structure(subsid) in destination — substruc(name) 

134.0 type; GetDomain : Subsid ^ Structure ^ Name -set 

.1 T)re- GetDomain(subsid, structure) ^ 
.2 subsid £ dom structure A 

.3 let mk- Substructure(substruc, ) — structure (subsid) in is- Map (substruc) 

A DOst- Get Do main (subsid, structure) (ns) ^ 

.5 let mk- Substructure (substruc. attrs) — structure ( sub sid) 'm ns — dom substruc 



The Structure Attribute Operations. 
135.0 type .- AddAtiribute : ... 



136.0 type ; RemoveAttribute : ... 



137.0 type : AssignAttribute : ... 



138.0 type ; Read Attribute : ... 



-166- 



A Multi-Tiered Approacli to Hypertext Integration: 
Negotiating Standards for a Heterogeneous Application Environment. 



Catherine C. Marshall 

Xerox Palo Alto Research Center 
3333 Coyote Hill Road 
Palo Alto, California 94304 



Submitted to the NIST Hypertext Standardization Workstiop, Gaithersburg, Maryland, January 16-18, 

1990 

Hypertext is most useful as a technology when it is embedded in an application: a paperless technical 
manual, a notetaker, a specification management system, or any other task domain where it is useful to 
represent and manipulate the structure of text. We feel that it is important to connect system 
requirements for hypertext with the situation of use; thus standardization efforts should be directed at 
enhancing the ability to embed hypertext in heterogeneous applications environments. 

This paper addresses a specific application and task environment - using hypertext as a medium for a 
shared notetaker that will be used in the intelligence community - and how it suggests a protocol-driven 
approach to integration. The work described in this paper includes an informal work practices study of 
the task environment, and the development of a functional specification for a hypertext system for 
notetaking. 

From the study and the development of a specification, we postulate that standardization of a 
multi-tiered system of linking protocols will help address the closed-world problem that we have 
encountered in NoteCards and many of the other second-generation hypertext systems without 
specifying rigid standards for applications that want to share information to a greater or lesser extent 
with a hypertext substrate. Such a system of protocols can be based in part on existing work on 
hypertext exchange and hypertext reference models. 

First we will briefly describe the task environment and present an informal model of the task. Then we 
will go on to describe linking and anchoring requirements in support of this task. Finally, we will argue 
that a multi-tiered system of linking protocols will not only meet the needs that we have already 
identified, but will be adaptable as the environment changes and will facilitate information sharing. It is 
this set of protocols that we propose should be standardized based on negotiations between 
applications developers and the hypertext community. 



-167- 



An Informal model of analytic activities 

The specification we developed describes a hypertext system to support intelligence analysts in their 
notetaking and other sense-nnaking activities. We based the specification on requirements derived 
during the course of an informal work practices study that we conducted at the user site, coupled with 
our previous understanding of the idea processing task (see [Halasz et al. 1987], [Trigg et al. 1986] , 
and [Trigg et al. 1987] for discussions of various aspects of idea processing in NoteCards). 

The analysts we studied work in a rich, complex environment of systems and information sources. 
From these sources they gather information, mostly by scanning the cables they receive through an 
institutional mail system, or by retrieving information from a variety of on-line resources (including 
outside information services like Dialog). They read and interpret information they gather, manifesting 
their interpretation in one of several ways. Sometimes they take notes on what they read or annotate 
the sources before filing them in their personal on-line or hardcopy file systems; in other cases they 
reflect their understanding of the material by simply filing source material or organizing it in response to 
a specific assignment. The product of this interpretation process is usually either a formal written 
analytic paper, or a shorter (and less formal) article. 

Thus, information gathering and retrieval, interpreting sources through notetaking and filing, and 
authoring reports are all important parts of the analytic task. These processes interact in a variety of 
ways: notetaking can be driven by information gathering, culling an electronic mail Inbox, or it can be 
driven by the production of a written report. Retrieval needs may be refined in the interpretation 
process as the analyst tries to make sense of the information at hand, or they may be related directly to 
a specific assignment. Structures to organize information may also be dictated by either sources or 
products, or by the internal models of a domain that an analyst has evolved over his or her career. 
Finally, presentations may be prompted by analytic requirements, or they may be driven by new 
interpretations that come out of the earlier processes in the flow. 

Furthermore, we found that the broader categories of analytic information processing are collaborative 
or coordinated with people in other organizational roles. Interpretation is often collaborative, sometimes 
involving telephone conversations, or (less commonly) informal face-to-face meetings. Interpretive 
collaboration is initiated by three different types of questions: (1) "What do you make of it?" (2) "Do 
you agree with this (or can you corroborate this)?" and (3) "What are the implications of this?" If the 
collaboration looks to be fruitful, a draft-passing co-authorship is negotiated between the two analysts, 
hence starting a presentation-phase collaboration. Coordination occurs in retrieval tasks in two ways: 
(1) Some members of the analytic work group have specific expertise in retrieval and can help an 
analyst gather information he or she needs from the institutional or outside sources. (2) Some analysts 
have specific resources (like their own extensive files); it is a coordinated effort to locate the desired 
information from those files. 



-168- 



Figure 1 sketches the flow between the categories of analytic activities and shows how they nnay be 
conducted in a collaborative setting. 



searching 



interpreting 



presenting 



notetaking 



retrieving 




-i V / 
filing 



writing 



coordinated 
retrieval 



collaborative 
interpretation 



draft- 
passing 



review cycle 
coordination 



Figure 1 . Analytic information processing activities 



In order to determine requirements for hypertext in the context of this task environment, it is important 
to investigate three areas: (1) where the information comes from; (2) the relationship between the kinds 
of notes analysts take and the information sources; and (3) what use the information is put to after the 
interpretation is complete. From looking at (1) and (3), we will be able to determine a strategy for 
integrating hypertext into an applications environment, and from (2), we will understand requirements on 
linking pieces of information together. 

Where information comes from. The analysts we studied use a variety of sources, some currently 
available on-line or destined to be on-line in the foreseeable future, and others that will continue to be 
available only in hardcopy forms. Frequently cited anecdotal evidence suggests that only five percent 
or so of the available data is ever used in analysis; therefore, analysts all feel very strongly about pulling 
in material from a variety of sources and processing as much of it as possible. It is a widely held belief 
in the intelligence community that contradictory analytic results stem from the use of different sources, 
rather than from different interpretations of the same facts. 

We have categorized the sources of on-line information that analysts use into four groups: personal files 
and databases, information from systems maintained by the analyst's working group, information from 
institutional databases and mail systems, and information maintained external to the organization such 
as open literature databases. These catagories suggest that there are varying degrees of control that 
hypertext developers will have over the systems and databases supplying this information. At best - as 
in the case of personal files and working group databases - the hypertext substrate will be able to 



-169- 



represent and display the information at both ends of a link; at worst - the cases where connmercial 
information sources are used - the hypertext substrate will only be able to represent a method for 
initiating the outside application. 

In our study, the most important source of day-to-day on-line information is the institutional mail system 
that supplies each analyst with cable traffic, filtered by an interest profile. Each analyst described a 
process of going through the day's institutional mail in a linear sequence and deciding which messages 
are of interest. Currently, these messages are hardcopied for further processing, mainly highlighting 
and otherwise marking them up. Therefore, the most prevalent example of where the information 
comes from falls between the two extremes. 

How notes are related to sources. The analysts we studied exhibited a range of notetaking styles. 
Many of them relied strictly on annotative notes; that is, they would make hardcopies of source 
materials, and mark up the pages. Annotative notes are taken in two different ways. Often, a 
broad-tipped highlighting pen is used to go over words, sentences, or paragraphs of particular interest. 
Some analysts have a preference for specific colors when they are doing this type of highlighting 
annotation. The second annotative style of notetaking involves writing short notes in the margins of the 
hardcopy. For example, one of the analysts marked things he did not believe to be true, or that he 
found anomolous; he noted those beliefs in the margins. Annotative notes are closely bound to 
selected segments of text; in hypertext terms, they reiy on access to a portion of the content of a node. 

We found that the analysts also use interpretive notes to record hypotheses, conclusions they have 
reached, or material they have integrated from several sources. These notes are frequently taken 
on-line in the text editor; sometimes this style of notetaking involves a significant amount of retyping to 
associate notes with their sources. Analysts also take interpretive notes that do not refer directly to any 
source, or that refer to a computational model. Interpretive notes are less tightly bound to individual 
words or sentences in a document. More often, they refer to a general assimilation of the document's 
content. Thus they frequently point to what would be represented in hypertext as a node. 

All of the analysts in our study made some use of reminding notes, Post-its or other jottings on paper 
that serve to jog their memory about things to do (an agenda of subtasks) or portions of procedures to 
follow (for example, how to log on to a given outside data service, or how to retrieve a piece of 
information). Reminding notes may be an important way of preserving procedural knowledge. These 
notes often do not refer directly to a node or its content, but rather how to get to it; they can be thought 
of as referring to the link. 

Figure 2 summarizes the three categories of notetaking styles we observed in the work group. 



-170- 













Highlighting of text and 
keywords 




Interpretive or integrative 
notes referring to one or 
more sources 






Auxiliary notes 
documenting a systematic 
process 




nl II lUicl tl 1 BLllc^o 


Interpretive notes 


Reminding notes 


Annotations and 
comments in the margins 




Text notes not referring to 
any source directly 






Auxiliary notes listing an 
agenda of subtasks 















Figure 2. Analysis of notetaking styles 



How information is used. Information is used two ways: analysts build up personal files and they 
write analytic reports and short articles, artifacts recognized by the community. This paper will not 
discuss our findings about how notes and collected information are filed. Instead we will focus on the 
use of information in analytic products, since one analyst's filing structure is usually opaque to the other 
analysts. It is difficult for analysts to retrieve information from one another's files, and once an analyst 
leaves the organization, his or her files quickly deteriorate in value. Thus, in order to make the 
information useful to anyone else, the analyst must either document this structure or publish any 
interesting analytic results. 

Two kinds of analytic products are supported by the institutional system, formal publications and shorter 
articles. These analytic products are created by integrating on-line sources and notes, and collections 
of annotated hardcopy material. Most of the analysts pull out their collection of materials on the desired 
subject to create a context for writing and to maintain traceability, which is universally cited as an 
important requirement on (and role for) hypertext. In all cases, the publication of an analytic product, 
and the subsequent usefulness of the document or article is directly related to the ability to, in hypertext 
terms, follow its links back to the sources. 

Once an analytic product has gone through the coordination cycle, it may be used by low level 
policy-makers, by various staff members, and by other analysts (sometimes affiliated with different 
agencies). Analysts expressed a desire for a "lighter weight" analytic product in order to share smaller 
chunks of analytic results with their community and receive credit for coming up with these results; in 
hypertext terms, we might think of this as sharing an interpretive layer over a heterogeneous collection 
of databases. 

Linking and anchoring to support of notetaking 

From our observations about notetaking in the analytic process, we have derived a set of requirements 
on links, how they are anchored, and what this implies about an integration strategy. 



-171- 



Links are named, typed, and have direction . Because we expect a variety of relationships between 
nodes (for example, an analyst might want to specify relationships like source, supports, or refutes), 
links must be named. Furthermore, since we expect links to have different characteristics, links must 
have types, so that a behavior can be associated with the named link. In NoteCards, we have found 
that the ability to specify the directionality of a relationship to be somewhat difficult for users; however, 
we still feel that representation of the direction of a link may be useful for expressing dependencies. 

Links are n-ary. For a hypertext notetaker, n-ary links are important for representing the relationships 
implied by what we have called interpretive notes. An interpretive note can integrate or synthesize the 
information in more than one source; hence, the link from the note to the source would require multiple 
endpoints to accurately represent what is going on in the notetaking process. Figure 3 illustrates an 
n-ary link example. In this example. Note #1 integrates material from the highlighted portion of Source 
A and Source B. 



Source A 




Figure 3. Example of how n-ary links may be used in the notetaker 

Links can either connect nodes or refer to nodes. There are two different notions of linking in 
hypermedia systems. Reference links are components within a node that contain a name or address 
that refers to another node (or a region within another node), or a procedure for retrieving that node; 
thus a link's destination can be computed at traversal. Reference linking is important in the case where 
an analyst is performing a query to an external database and wants dynamically computed results. 

Connection links are components that connects a node or region within a node with another node or a 
region within it; the objects at both ends of the link "know" about the link. For the purposes of the 
notetaker, connections will provide a stronger tie between the information at the source and the 
annotative or interpretive note at the other end oi the link. 

Links can be anchored In a span of text. A link anchor is the span within a node corresponding to the 
endpoint of a link. In some hypermedia systems the span may be limited to a single point (eg. 



-172- 



NoteCards [Halasz et al. 1987]) or to the entire node (eg. gIBIS [Conklin & Begennan 19881). Other 
anchoring schennes (eg. Intermedia [Garrett et al. 1986]) may allow anchors to encompass arbitrary 
extents of text (or graphics) within a node. 

Analysts' notetaking practices suggest a need for "span-to-span" links, where an arbitrary region or 
collection of objects can be connected with another arbitrary region or collection of objects as illustrated 
in Figure 4. Span-to-span linking is important to the notetaker because most source-connected notes 
that analysts take generally refer to a region of text. Furthermore, it is important to identify which parts 
of a multi-source note or a document refer to which sources. 




MoteCards has point-to-node links. 



Figure 4. Span-to-span linking 

More specifically, span-to-span linking supports the kind of annotative notetaking that we have 
observed. The anchoring and marking process is similar to the highlighting that analysts use to set 
apart a region of text. In this case, it is the delimiting of text that is important; a special link type can 
support this span-to-null link. The ability to include marginalia as annotations depends on using a 
span-to-node or span-to-span link. See [Catlin et al. 1989] for an example of how span-to-span linking 
can support annotation. 

Links are marked to reflect their properties. Link markers are the method by which the system 
indicates the presence of a link anchor to the user. What information a link marker displays should 
reflect its function. Link markers in the notetaker should allow an analyst to detect the presence of a 
link without requiring extra action (as an annotation can be detected), distinguish the level of integration 
of the link's destination, and determine the scope of the anchor's span (as highlighting shows scope). 

Links can be annotated. Because procedural or reminding notes sometimes refer to links, rather than 
to nodes, links should have the ability to be annotated. In the case of very shallow linking (where the 



-173- 



actual reference is not sufficient to resolve what should be at the other end of the link), link annotation 
can supplement automated link resolving mechanisms. 

Levels of integration 

This set of requirements on links, coupled with the analysts' need to trace notes and finished 
intelligence back to its sources and their use of a variety of tools in the sense-making process, leads us 
to a multi-tiered integration scheme. Of the different tools and applications available in the analysts' 
environment, some will be more amenable to deep integration than others. Furthermore, we have found 
that the various kinds of notes that analysts take require greater or lesser connection to outside 
information, and that in some situations, the payoff for deeper integration is large, while in others, 
shallow integration is all that is necessary. 

We have divided integration into three levels, listed in order of depth: (1) data or content based 
integration; (2) tool or node based integration; and (3) display or window based integration. This list 
suggests a need for three protocols, which we feel are general to embedding hypertext in a 
heterogeneous application environment: an anchoring protocol, a linking protocol, and a launching 
protocol. Figure 5 summarizes the relationship between the protocols and the depth of integration. 



DEPTH 


PROTOCOLS 


anchoring 


linking 


launching 


data/ 
content 




m 




tool' 
node 








display/ 
window 









Figure 5. Relationship between protocols and depth of integration 

At the deepest level, integration requires access to the content of a node. Integration at this level 
implies that applications must obey an anchoring protocol to describe the extent of the anchor within the 
node, a linking protocol to retrieve nodes from applications outside the notetaker, and a display protocol 
so the notetaker can present the node in a suitable window. Deep integration makes it possible to treat 
information from outside the hypertext system the same way as it is treated within the system; thus 
traversing in a link is the same as it would be were the node maintained by the notetaker. 

At the next level of integration, linking is supported so nodes of information from other applications can 
be included; in this case, the application only needs to implement the linking and display protocols. In 
this case, traversing a link is a retrieval of a piece of information outside the notetaker. 



-174- 



Display-based integration is the most superficial of the three levels. The purpose of display-based 
integration is to provide access to outside tools; at this superficial level of integration, traversing a link is 
a launch of an application in a window. 

Figure 6 shows a hypothetical notetaking situation, where an analyst has taken a note referring to three 
outside sources, one at each level of integration. The first text span of the note is integrative, and 
refers to the first two outside nodes; protocols tell the notetaker how to launch each application and 
retrieve the appropriate node. Because the node fronn the first application supports anchoring, the 
extent of the anchor's span is also marked. The note's second span of text refers to the entirety a 
node in the second application; linking is supported, but anchoring is not, so only the node can be 
retrieved and displayed. The third span of text in the notetaker's node refers to some portion of the 
application launched in the third window. Since neither linking nor launching is supported, the 
application can only be brought up in a window. The annotation on the third link object is the user's 
procedural note describing how to get the proper information from the third application. 



Outside sources 



Node from 
application #1 
that supports 
anchoring 
protocol 



Node from 
application #2 
that supports 
linking protocol 



Window from 
application #3 
that supports 
launching 
protocol 



N'l'iViViViViVi'i'i'i iV I I't'iVi'i'iVA 



Link objects 



launch application 
^Ink destination 
anchor span 

link source 
anchor span-^ 

launch application 
Jink destination 



no anchor 



launch application 
link destination 
no anchor 



link source 
anchor span 




launch application 
no link 



no anchor 



link source, 
anchor span 



annotation 



Note (node) 
maintained by 
notetaker 




Figure 6. Hypothetical notetaking situation contrasting levels of integration 



Defining the three levels of protocol will allow the launching, linking, and anchoring specifications to be 
expressed and stored in the link objects, and understood by the outside applications to the degree that 
they support the protocols. 



-175- 



Conclusion 



In this paper, we argue that standardization efforts should not only be concerned with a hypertext 
reference model, but also a multi-tiered system of protocols for integrating information from a 
heterogeneous applications environment. We make this argument using evidence from a study of a 
sense-making activity, taking notes in the performance of an intelligence analysis task; we feel that this 
activity is representative of a wider class of idea processing tasks, and that the applications environment 
shares many characteristics with other environments where hypertext will provide particular leverage on 
work involving representing and manipulating the structure of text. 

The study we have performed shows that the closed-world assumption at the root of many 
second-generation hypertext systems limits the ultimate usefulness of those systems, and that future 
hypertext work must consider at least partially open architectures. Thus creating standards for 
hypertext necessarily includes developing protocols for integration of outside applications. Our results 
suggest that three levels of protocols will be useful, an anchoring protocol, a linking protocol, and a 
launching protocol. These protocols can be closely tied to the reference model adopted by the 
hypertext community (see [Halasz & Schwartz 1989]) to ensure a common description of what is 
included in each protocol. 

Acknowledgements 

I'd like to thank Frank Halasz for some helpful discussions during the development of the notetaker 
specification. 

References 

[Catlin et al. 1989] Catlin, T., Bush, P., and Yankelovich, N., "InterNote: Extending a Hypermedia 
Framework to Support Annotative Collaboration," Proceedings of Hypertext '89, Pittsburgh, 
Pennsylvania, November 5-8, 1989, pp. 365-378. 

[Conklin & Begeman 1988] Conklin, J. & Begeman, M., "gIBIS: A Hypertext Tool for Exploratory Policy 
Discussion," ACM Transactions On Office Information Systems Vol. 6, No. 4, October, 1988, pp. 
303-331. 

[Garrett et al. 1986] Garrett, L.N., Smith, K.E., and Meyrowitz, N., "Intermedia: Issues, strategies, and 
tactics in the design of a hypermedia document system," Proceedings of the Conference on 
Computer- Supported Cooperative Work, Austin, Texas, December 3-5, 1986, pp 163-174. 

[Halasz et al. 1987] Halasz, F. G., Moran, T. P., Trigg, R. H., "Notecards in a Nutshell," Proceedings 
of the /ACM CHI + GI Conference, pp. 45-52, Toronto, 1987. 

[Halasz 1988] Halasz, F.G. "Reflections on NoteCards: Seven Issues for the Next Generation of 
Hypermedia Systems," Communications of the ACM, Vol. 31, No. 7, July 1988, p. 836-852. 

[Halasz & Schwartz 1989] Halasz, F.G. & Schwartz, M., "A Reference Model for Hypertext," Submitted 
to the Hypertext Standardization Workshop, Gaithersburg, Maryland, January 16-18, 1990. 



-176- 



[Trigg et al. 1986] Trigg, R. H., Suchman, L., Halasz, F. G., "Supporting Collaboration in NoteCards," 
Proc. of Conference on Computer Supported Cooperative Work, Austin, Texas, December 3-5, 1986, 
pp 153-162. 

[Trigg et al. 1987] Trigg, R. H., Moran, T. P., Halasz, F. G., "Adaptability and Tailorability in 
NoteCards," Human-Computer Interaction - INTERACT '87, H.-J. Bullinger & B. Shackel (Eds.), Elsevier 
Science Publishers B.V. (North-Holland), 1987. 



-177- 



10. Newcomb, Steven R. - Explanatory Cover Material for Section 7.2 ofX3V1.8M/SD-7 
Explanatory Cover Material for Section 7.2 of X3V1.8M/SD-7, Fifth Draft. 

Steven R. Newcomb, 
Vice Chairman, X3V1.8M, and 
Associate Director, Center for Music Research, Florida State University 

The mission of the ANSI X3V1.8M Music in Information Processing Standards (MIPS) 
committee is to develop a Standard Music Description Language (SMDL) to enable 
interchange of musical documents. The committee has chosen to represent the structure 
of the information represented by SMDL as a Standard Generalized Markup Language 
(ISO 8879-1986) Document Type Definition (an "SGML DTD"). 

In the course of its work (which began in 1986), the MIPS committee developed a 
general model for the representation of schedules for the execution of events. WTien it 
confronted the problem of representing music in several of its normal contexts, such as 
the interdependently synchronized lighting, staging, and orchestra cues in musical 
comedy and opera, the MIPS committee developed SGML-based means of representing 
links within and among documents. These means are what is set forth in the following 
extract (Section 7.2 ["General Links"] of the fifth draft of X3V1.8M/SD-7 
["Hypermedia/Time-based Document Subset"]. 

When it became clear that this model would be useful for the representation of the 
scheduling of non-musical (as well as musical) events multimedia and hypermedia 
documents, the committee extracted the time model from the other, strictly music-related 
portions of SMDL, gave the model a name ("HyTime"), and placed it in its own Standing 
Document, X3V1.8M/SD-7. In the current draft of SMDL, Standard Music Description 
Language (SMDL) is an application of HyTime. (The rest of SMDL is described in 
X3V1.8M/SD-8.) 

When HyTime 's "General Links" facilities were discussed at the NIST Hypertext 
Workshop, it tumed out that the Dexter, Intermedia, and HyTime models all decomposed 
the problem of document addressing in much the same way, although their jargon was 
dissimilar. The "Room 705 Ad Hoc Group" (Ed Fox, Steve Newcomb, Tim Oren, and 
Victor Riley) succeeded in showing how the "anchor" concept in the three models could 
be merged. It is anticipated that the NIST Hypertext Workshop will have significant 
impact on succeeding drafts of HyTime. 



-179- 



X3V1.8M/SD-7 



X3V1.8M/SD-7 Fifth Draft 



August 11, 1989 

X3V1.8M/SD-7 Journal of Development 

Standard Music Description Language (SMDL) 

Part Two: Hypermedia/Time-based Document Subset (HyTime) 

EDITORS: 

Charles F. Goldfarb, IBM Almaden Research Laboratory 
Alan D. Talbot, New England Digital Corporation 



Includes work as of June 22. 1989. Effective through October 31, 1989 



7.2 General Links 

General links are relationships between documents or parts of documents. The set of 

potential general links is infinite, so the mechanisms provided by HyTime are extensible by 
users and applications. 



Note: The term "general link " is used in preference to the unqualified term "link" to 
avoid confusion with the SGML link feature. However, there is no problem in using 
"link" with more restrictive qualifying adjectives, as in "hypertext link," or with no 
qualifiers when the context is clear. 

Some forms of general link occur in all documents, not jusi those intended for hypertext and 
hypermedia access. Those forms are represented by inherent SGML functions, so HyTime 
does not need to address them. 

Note: Some examples are: 

— Links that associate a semantic role (such as "paragraph" or "heading") with an 
element are represented in SGML by generic identifiers. 

-■ Other links that associate a property with an element (rather than associating two 
elements with one another) are usually represented in SGML by attributes. 

Note: (""EDITOR") We may want a specialized link element nonetheless, 
for those cases in which the document cannot be modified to add an 
attribute. 



-180- 



X3V1.8M/SD=7 Fifth Draft 



— Links that specify layout or typography, or other processing of a document, are 
represented by the SGML link feature. 

— Links between the logical structure of the document and physical storage are 
expressed by the SGML entity mechanism, which includes the ability for a user to 
segment and link a document physically on whatever boundaries he requires. 

The following forms of general link are supported by HyTime. either via inherent SGML 
mechanisms, or by elements and attributes defined in this Standard. (The list is derived 
from "A Tentative Listing of Some Linktypes" on pp.4/52-4/55 of Ted Nelson's Literary 
Machines, Edition 87.1) 

Note: ("EDITOR") This list represents one view of the requirements for general link 
support, and as such provides an initial touchstone against which to evaluate the 
language design. It is provided merely as a starting point, and it is expected that 
others will suggest additions and modifications to both the list and the design. 

a) metalinks 

title 
author 

author (external claim) 
document supersession link 

b) ordinary text links for sequential documents 

correction link 
comment link 
counterpart link 
translation link 
heading link 
paragraph link 
inclusion 

quote-link (annotated inclusion) 
layout, typography, epigraphy links 
footnote link 

c) hypertext links 

vanilla jump-link 
modal jump-iinks 
suggested-threading links 
expansion links 

d) literary links 

citation link 
alternative-version link 
comment document 
certification links 
mail link 

Links can also solve the unique structural problems of interactive multimedia documents, 
such as instructional materials. For example, when the normal sequence of elements is 
interrupted by a user response, links in audio material could indicate suitable jumps to 
graceful endings. 

In HyTime, general links all consist of one or more "link ends" (Nelson calls them "end 
sets"), together with a description of the purpose of the link (the "link type"). A general link 
also has an associated "link term" that an application displays as a "button" from which the 
link can be accessed. In character text, the link term is a word or phrase that is the subject 
of the link, and the "button" is usually the link term in a highlighted font. In other data, the 
link term is a location (for example, a coordinate in a displayed image), and the button might 
be a cursor that changes shape when it is over the link term location. 

Note: ("EDITOR") Do we need the potential for a link term at each link end? 

HyTime includes four element types that represent general links: 



-181- 



X3V1.8M/SD.7 Hfth Draft 



— The independent link is the most flexible. It can have any number of link ends and they 
can be in any documents, even those to which there is no write access. 

— The contextual link has oniy two link ends, one of which is at the location of the 
contextual link element. 

— The excerpt is a special form of contextual link that is used for including portions of other 
documents, with or without acknowledgment. 

— The location reference is a special form of contextual link that is used for automatic 

cross-referencing within a document. 



7.2.1 Sudependant Link 

The element independent i'mk (ilink) represents a general link whose link ends are 
independent of the ilink element itself. The content of the iiink element, if present, is the link 
term. 

An independent link occurs, as its name implies, out of the normal context of the document. 
Its location need have no connection with the location of its link ends. 

Note: An iiink can be used in situations where it is not possible to modify the link 
end locations. If one of the link ends can be modified, it may be more convenient to 
use a contextual link (see 7.2.2). 

The attribute iinkends {link ends) identifies one or more locations that are the subject of the 
link. Each can be a document location, data entity location, or some other element, 
including another general link. The number of link ends, and their meaning, are a function 
of the link type, which is determined by the application. 

The attribute Iwdepersdentt JSnk.typ® {ilinktyp) identifies the purpose of the link. The possible 
values are determined by the application. 

Note: Uses for independent links include comments and notes by reviewers and 
collaborative authors, external thesauri and indexes, and identification of various 
kinds of alternative versions. 

The attribute link term (linkterm) identifies the link term of the link. If not specified, the 
content of the ilink element is the link term. 

The entity a.ilink allows additional attributes to be defined. 



<!— 7.2.1 Independent Link — > 
<! ELEMENT ilink — Independent link: independent of its location (included) 
- 0 ANY » 

<i£NTITY % a.ilink « « — User-defined independent link attributes > 
<!ATTLIST ilink id — ■ Used when this ilink is linked to — 

ID ^IMPLIED 
linkends — Ends of link: element, docloc, or entloc — 

IDREFS #REQUIREO 
ilinktyp — Purpose of link (application-defined) — 
COATA flMPLIED Default: implied by GI 
linktenw — Index term or "button^ location — 

IDREF ^COMREF — Oe fault r content of ilink — 
%a. ilink; > 



X3V1.8M/SD-7 Fifth Draft 



7.2.2 Contextual Link 

The element contextual Vmk {clink) represents a general link with two link ends. One of the 
link ends is the content of the contextual link element, which must be valid in the context in 
which the clink element occurs. The content can be entity if the link end is simply a point in 
the text, rather than a span of a character string. 

A contextual link occurs, as its name implies, in context at exactly the location of one link 
end. The content of the contextual link element, if it is not empty, is the link term as well as 
a link end. It is also treated as part of the content of the containing element, just as if there 
were no dink tags around it. 

Mote: A clink can be used only if the link has only two ends and one of them can be 
modified to incorporate the clink tags. In other cases, the independent link can be 

used (see 7.2.1). 

The attribute linkend {link end) identifies the other end of the link. It can be a document 
location, data entity location, or some other element, including another general link. The 
meaning of the link end is a function of the link type, which is determined by the application. 

The attribute contextual link type {dinktyp) identifies the purpose of the link. The possible 
values are determined by the application. 

Note: Uses for contextual links include various forms of hypertext links and 
alternative access paths through a document. 

The attribute automat!c mtum {return) indicates whether processing of the document returns 
automatically to the end of the ciink after processing the link end. 

The entity a.cUnk ailows additional attributes to be defined. 



<!— 7.2.2 Contextual Link — > 
<! ELEMENT clink — Contextual link: nested subelement of Its parent — 
- 0 ANY > 

<!ENTITY % a. ciink " " — User-defined contextual link attributes > 
<!ArTLISTc1ink id — Used when this clink is linked to — 

10 ^IMPLIED 
linkend — Other end of link: element, docloc, or entloc 

IDREF *?REqUIRED 
clinktyp -» Purpose of link (application-defined) -- 

COATA #REQUIRED 
return Automatic return at end of linkto element — 

(return I noreturn) roreturn 
%a. clink; > 



7.2.3 ExcerpS 

The SGML external entity reference is the normal vehicle for including text from one 

document within another. Such inclusion is transparent, in the sense that if the included 
material is itself represented ini SGML, an SGML parser will deal with it without advising the 
application program. Therefore, iff an application wishes to acknowledge that certain 
materia! is included from other documents, an additional construct is required. 

The element ascerpi {excerpt) is a type of contextual link that identifies a portion of another 
document (the "excerpt source") that is included in this one. In other words, the excerpt 
source replaces the excerpt element. The included text must be valid in the context in which 
the excerpt element occurs. 



-183- 



X3V1.8M/SD-7 Fifth Draft 



The attribute quote {quote) indicates whether the existence of the inclusion is nnade evident 
to the reader of this document. 

The attribute excerpt source {xsource) identifies the location of the text to be included. It 
points to a document location or data entity location element that describes a location in a 
document other than the one in which this excerpt element occurs. 

The attribute aciknowiedgmertt {ack) identifies the location of acknowledgment data for the 
included material, such as a copyright notice. The acknowledgment can be in any notation 
suitable for use in conjunction with the included material; for example, an image that can be 
overlayed on an included video clip. 



<! ELEMENT excerpt 
<!ATTLIST excerpt 



<!— 7.2.3 Excerpt — > 

Part of another document included in this one — 
» 0 EMPTY > 
id ID ^IMPLIED 

xsource IDREF ^REQUIRED 
quote — Reveal existence of excerpt — 

(quotejnoquote) noquote — Default: conceal — 
ack — Acknowledgment text 

IDREF illMPLIED > 



7.2.4 Location Reference 

Applications that use HyTime will frequently define specialized link elements for 
cross-references to headings, footnotes, and figures. When a document is presented, the 
reference elements are replaced by the heading text, footnote numbers, or figure captions of 
the elements to which they refer. The location reference element, in conjunction with the 
location elements defined later, offers a generalized mechanism for such cross-references. 

The element location reference {locref) is a form of contextual link whose other link end is a 
location element. An application will normally process a location reference by replacing it 
with diata that is derived from (but is not necessarily identical to) the content of the link end. 

Note: A location reference therefore differs signficantly from an entity reference: the 
latter, is an SGML construct whose behavior is defined precisely by ISO 8879, while 
the behavior of a location reference is entirely application-dependent. 



<!— 7.2,4 Location Reference — > 
<! ELEMENT locref — Reference to a location element — 

- 0 EMPTY > 
<!ATTLIST locref id ID #IHPLIED 

idr IDREF #REQUIRED » 



7.2.5 Locations 

A general link must refer to one or more locations in documents. SGML provides two 
inherent constructs for identifying locations: 

a) A unique identifier ("ID") attribute, which identifies a complete element in the same 
document as the reference to it. 



-184- 



X3V1.8M/SD.7 Fifth Draft 



b) An entity name, which identiries a complete entity (frequently data without SGML markup) 
in the same document from which it is referenced. 

These constructs are insufficient by themselves for general links, because the link ends of a 
general link could be outside the document in which the link occurs, or they could constitute 
only a portion of a data entity or element. For these reasons, HyTime supplements these 
constructs with several "location" elements that can be used separately and in combination 
to represent the following locations: 

a) In a data entity, a point or a span of data, either. 

1) in terms of a data content notation (e.g., a video frame number, a coordinate in space, 
an offset in time); or 

2) in terms of the uninterpreted characters. 

b) In an SGML document or subdocument entity, either 

1) the entire document or subdocument; or 

2) some identified element within it; or 

3) some data location within the identified element (interpreted or uninterpreted). 

Note: ("EDITOR") In the next edition, the element location facility will be 
extended to address a span from one element location to another. 



7.2.5.1 Data Entity Location 

The element data entity location (entloc) identifies a portion of a data entity. The data could 
be "character set data." or it could be "notation data." which must be interpreted according 
to a particular data content notation. The portion could be a single point, or a span of data 
betv/een two points. 

The attribute data entity name {dataent) identifies the data entity to which the data entity 
location refers. If not specified, the data entity is the same as that of the previous entloc 
element. 



<!— 7.2.5,1 Data Entity Location --> 
<! ELEMENT entloc — Identifies a portion of a data entity -- 

- 0 (cdloc I ndloc) > 

<!ATTLIST entloc id ID ^REQUIRED 

dataent ENTITY #CURRENT — Default: previous entloc — > 



Character Set Data Location 

The element character set data location (cdloc) defines a single point in character set data, 
or a span of data between two such points. 

The element character set data point {cdpoint) defines a point in character set data. The 
point is represented as an integer offset from the first character in the data. A value of 0 
refers to the point prior to the first character, except when only one cdpoint is specified in a 
cdloc, in which case it refers to the point after the last character 

Only characters that an SGML parser passes to an application are counted (for example, a 
record end after a start-tag is not normally treated as a data character). 



-185- 



X3V1.8M/SD-7 Fifth Dralt 



<!— 7.2.4. LI Character Set Data Location — > 
<!ELD1ENT cdloc — Character set data location — 

— 0 (cdpoint, cdpoint?) > 
<! ELEMENT cdpoint — Character set data point — 

— Offset from first significant character — 

— 9 » before first char (after last if only one cdpoint) — 
0 0 (#PCDATA) > 



Notation Data Location 

The element notation data location {ndloc) defines a point or a span between points in data 
that is subject to interpretation by a data content notation. The representation of the point or 
span is not defined by this standard; it depends upon the notation in which the data itself is 
represented. 

In HyTime applications, the data would normally represent occurrences in space, time, or 
both, so a notation data location would consist of offsets on a visual coordinate system, 
and/or elapsed time values. Some notations also provide the ability to "label" items for 
identification, in such cases, a notation data location could refer to such labels. 

The attribute snap {snap) indicates whether the specified location should be adjusted to 
conform to alignment or synchronization points in the data. The specified location can be 
"snapped" to the nearest, next previous, or next following alignment point, or not at all. 

Note: Graphics representations commonly have an associated "grid" to which 
objects can be "snapped" in order to assure alignment and/or a minimum resolution. 
Similarly, representations with an internal time bases frequently include 
synchronization points, such as frame markers in SMPTE encoding of movies and 
video. 

Note: ("EDITOR'*) It may be possible to define a generalized method of referencing 
space and time locations that would serve for a wide variety of notations. Such a 
method could be incorporated into HyTime as the definition of an ndloc element. The 
snap attribute is an example of one possible parameter. Suggestions are invited. 



<!— 7.2.4.1.2 Notation Data Location — > 
<!ELEMENT ndloc — Notation data location — 

— Offset in time or space and duration or size, or label 

- 0 (formula) — Depends on data content notation 
<!ATTLIST ndloc snap Specified point is changed to aligned point — 

(nearest! before i after 1 none) none > 



7^.5^ Document Location 

The element document location (docloc) identifies a portion of an SGML document by 
means of an optional element location, and an optional data location within that element. If 
no element location is specified, the "element" is the entire document. If an element 
location is specified, but no data location, that complete element is the "document location." 

The attribute document entity {docent) identifies the entity in which the document begins. If 
omitted, it is the same entity in which the docloc element occurs. 



-186- 



X3V1.8M/SD-7 Fifth Draft 



<!-- 7.2.4.2 Document Location --> 
<!ELD-1ENT doc^oc — Identifies a portion of a document or subdocument — 
-- Entire document if element location is omitted — . 

— Entire element if data location is omitted — 

- 0 (elemloc, (cdloc | ndloc)?)? > 
<!ATTLIST docloc id ID ^REQUIRED 

decent ENTITY #IMPLIED ~ Default: this document — > 



Element Location 

The element element location {elemloc) identifies an element either by a unique name, or by 
a sequence of "node locations," called a "node path." The element location permits a 
general link to refer to an element in a different document, or to an element (in any 
document) that does not have a unique identifier attribute ("ID"). 

The attribute element identifier {elemid) is the unique identifier ("ID") attribute of the 
element whose location is being identified. If the element has no unique identifier, its node 
path is used instead. 

Notes: 



a) The attribute elemid is not declared to be an "IDREF" attribute because its value may be 
an ID from another document. An SGML parser will normally check for the validity and 
uniqueness of an lOREF, but cannot do so for an ID from another document, as it could 
conflict with an ID from this document. 

b) The keyword "#CONREF" identifies a "content reference attribute." If a value is specified 
for the attribute, the SGML parser will expect the content to be empty (and vice versa). 
The application is expected to use the attribute value in some way as a substitute for the 
data that would ordinarily have been in the content. 



<!— 7.2.5.2.1 Element Location --> 
<!ELEr'1ENT elemloc — Identifies an element of a document or subdocument — 

- 0 (nodeloc+) > 

<!ATTLIST elemloc elemid NAME #CONREF -■■ Default: use node path — > 



Node Location 

The element node location {nodeloc) identifies the sequential position of an element among 
its siblings in the tree structure of the document. The node location is an integer greater 
than zero, and each separate data portion in mixed content is treated like an element when 
counting. 

Note: For example, in a paragraph consisting of some character data followed by a 
quotation element, and then some more character data, the first character string 
would have a node location of "1," the quotation a node location of "2," and the 
second character string a node location of "3." 

Any element, including the pseudo-elements containing the data in mixed content, can be 
identified uniquely by a "node path" consisting of an ordered sequence of the node locations 
of itself and its ancestors, starting at the root of the document tree. 



-187- 



X3V1.8M/SD-7 Fifth Draft 



Note: For example, in a document with the following structure: 
<corexTrenseqxcesxce><ce></ces></mmseq><batonxtempo><tempo></baton></core> 
the second tempo element can be Identified by the node path: 
1 2 2 

An element that is empty or that contains only data (including the pseudo-elements 
containing data in mixed content) is a leaf of the document tree. Its data does not have a 
node location, but can be addressed with a data location element. 



<!— 7.2.5.2.2 Node Location — ■> 
<! ELEMENT nodeloc — Node location: integer > 9 (each fUPCDATA is one) - 
- 0 (#PCDATA) > 



7.2.5.3 Point Location 

The element point location (pointloc) Identifies a point in an element so that it can be 
referenced. Its content, which is optional, can be used by an application to describe the 
point. 

Mote: For example, when printing a cross-reference to it. 



<!— 7.2.5.3 Point Location --> 
<! ELEMENT point! oc — Identifies a point in an element — 

Content can be used by application to describe point — 

- 0 ANY > 

<!ATTLIST point! oc 1d ID #REQUIRED > 



-188- 



Toward Open Hypertext: Requirements for 
Distributed Hypermedia Standards 

A Position Paper for the NIST Hypertext Standards Wori<shop 
Tim Oren, Apple Computer 



1. Directions for Hypertext Standards 

Much discussion of hypertext standards has centered on the transfer of 
closed, static hypertext document bases among various platforms and 
organizations. V/hile there is an undoubted need focused on the use of 
hypertext with optical media and technical documentation, the thesis of 
this position paper is that any standard based primarily on this limited 
application will be necessarily flawed. 

The original vision of hypertext was a universally shared, dynamic 
"docuverse" v/hich could be read and written by all users. Although 
systems short of this grand vision have proven utility, we would not wish 
to abandon this future or the smaller scale visions of department and 
enterprise-wide hypertexts. Nelson proposed that one unified backend 
storage mechanism, "Xanadu," would solve the distributed hypertext 
problem for all [Nelson 80]. Though the Xanadu system is now advancing 
toward commercial release, it comes late in the day. There are already 
established commercial hypertext systems and sizable collections of 
content which are unlikely to be abandoned. 

Hence, if we want the docuverse to become reality, we must build it in the 
distributed, multivendor computing milieu of today. To bring together 
the diverse software and hardware systems already existing we will need 
abstract models of hypertext and ultimately standards based on the 
models. If this work is to be viable, the results must also reflect technical 
and market realities, and interaction with other areas such as multimedia 
and compound documents must be considered. In the remainder of this 
paper, I examine some of the requirement posed by these constraints, 
propose design principles for meeting these requirements, and suggest 
that an open system architecture should be the ultimate goal of hypertext 
standardization efforts. 

2. Technical Conditions 

Working in today's computing environment means working with existing 
networking and file standards. These are characterized by loose 
connectivity and modest reliability. Not only do LANs and WANs break 
down, but many connections are deliberately noncontinuous for cost 
reasons. Remote resources such as servers fail and go offline, often due 
to crashes that mean reloading earlier data versions. Existing file and 
device level utilities allow copying and alteration of file and document 
structures without warning to the applications which rely on them. All 
existing standard user interface systems are aimed at this level. These 
utilities are used routinely to remove partial document collections for 



-189- 



work at home or transfer to other sites, and to return modified versions to 
the original system. A hypertext standard for this environment must be 
robust when faced with a variety of insults to document identity and link 
integrity. 



layout doc 



layout doc 




\~I^JhTm "comcosilo" would be more fitting 
than "compound", but "compounc 
document" is already adopted by the 
international standards community. 

Page 7 



TV^jg jg a Title 



table doc 




mage library doc 



Figure 1. Compound document Figure 2. Hypermedia document 

Activity in hypertext standards interacts with other advanced document 
models. For instance, figure 1 shows a "compound document" where 
various text and graphical entities (E) are assembled into a page under 
the control of a layout specification. However, rather than storing the 
compound document as a single file, it might be realized as shown in 
figure 2. Here, a hypertext substrate is used to implement a compound 
document: the graphic entities are placed using links (L) to persistent 
selections (P) within other files. 

Links can encode dynamics and constraints as well as static information. 
In figure 2, the upper link specifies the transformation of the linked data 
into a graph. In figure 3, links are used to specify synchronization 
information for pieces of dynamic media. Finally, as suggested in figure 
4, the rise of object oriented software may make possible "component 
documents" where each entity may be edited in place by software modules 
selected at runtime by the user. Implementing a component software 
system will require a standard data storage substrate very similar to 
hypertext which vendors of individual components can use and extend. 

Because these issues and applications all interlock, it is not possible to 
restrict a discussion of hypertext standards to static text alone or to 
particular document models. A standard arrived at in this fashion will 
suffer one of two fates. At best, it will create a "golden ghetto" where a 
class of hypertext applications may live, but without connecting to other 
media types or document models. At worst, it may coopt and prevent 
progress in these areas. 



-190- 



storyboard document 



video document 



0:00:00 



0:07:19 



0:08:35 , 



The^ 



Opening scene. 
Fade in on LS of the 
street. 

Cut to MS of 
leopard. 

Sound efx "ROAR". 
Overlay "The end".^ 




animation document 



audio 
document 



Figure 3. Multimedia documents 



Secretariat 



# 


Secr-t 


avg 




1 


177.66 


680.00' 




2 


996.10 


10.00 




3 


314.14 


199.91 






This I e ) 
shows somt 
runaround tc 
show that Iho 
layout isn't jusi 
rectangles. 

The relations between frames is more 
complex than window panes. When 
a picture frame gets 
wider, the adjacent 
text column get: 
narrower and thus 
longer, which may 

wrap to another column. This may move 
another frame to a new page. Frames may 
even overlap! 

This document requires "fine-grainec 
window management' for its window. 



a gallop 



Plug-in software 
components 

Entities are edited in place 

The composition and text 
blocks could also be plug-in 
components 



Figure 4. Component documents 

In these examples the objects are not exclusively text. They include static 
bit map graphics and object graphics, dynamic animation, sound and 
video. Each of these data types represents a corresponding discipline and 
standards effort. A hypertext standard which restricts itself to text alone 
is crippled at the beginning. One which attempts to reinvent standards 
for each constituent media type would create a ghetto effect, and might be 
simply impractical given the effort required. It would seem that a 
hypertext standard must find a way to embrace existing media type 
standards with a minimum of modification. In the remainder of this 



-191- 



discussion, I use hypertext in its most general sense, to indicate the 
scheme for linking all data types, not just text. 

Hypertext as a functioning discipline is quite young, and disagreement 
and lack of understanding of systems architecture and application needs 
is still rife. There is controversy at even the fundamental level of 
linking method and storage organization. Various systems implement 
links as separate webs or within documents, and represent them 
abstractly or procedurally. A recent panel on system architecture makes 
it clear that there is still substantial change, with many systems seeking 
to adapt the better features of the other approaches [Halasz 89]. It is also 
clear that the diversity of systems is not gratuitous variation, but has 
occurred because of real differences in the intended applications and 
audiences. No "one right way" to do hypertext has emerged. 

Above the storage level, diversity increases further. Labelled links are 
used diversely, to represent constraints, timing, inferencing and 
rhetorical information for the use of both the browser and the software. 
User interfaces to large, interlinked data stores are an area of active and 
fruitful research. More complex architectural issues such as versioning 
and searchability are just beginning to be explored. Again, the various 
approaches and progress have been largely driven by the needs of 
particular applications. 

Attempts to standardize in a discipline in such flux must take account of 
the diversity of approaches if they are not to cripple progress. To the 
greatest extent possible, formalisms must embrace the diversity of 
architectures and applications rather than being exclusive or 
prescriptive. 

3. Market Conditions 

A standard must consider prevailing market conditions to be effective. In 
the case of distributed hypertext, the installed base of machines on 
networks is characterized by wide diversity of vendor, architecture, and 
hypertext software. Significant hypertext systems run on Macintoshes, 
IBM PCs and PS/2s, Sun, DEC and other Unix equipment, interconnected 
with a variety of LAN architectures, many also connected to long haul 
networks such as Bitnet or Milnet. Hypertext software is provided by both 
hardware vendors (HyperCard, Sunlink) and independent software 
vendors (KMS, HyperTIES, Guide). Initial market penetration of hypertext 
technology is occurring in the areas of in-house and external technical 
documentation and distribution of multimedia content, particularly on 
optical discs. Substantial commercial and academic efforts are underway 
to introduce hypertext as a mechanism for collaborative work in the 
computing environment. 

Given this diversity of platforms, the resemblance of distributed 
hypertext to the open systems efforts undertaken in networking and 
structured databases is obvious. The existing vendors, applications, and 
users will not be dislodged by either a proprietary specification such as 
Xanadu or a public standard. A successful effort must coopt existing users 
by extending their reach onto other platforms. It should become possible 



-192- 



to, for example, read nodes within HyperCard without being necessarily 
aware that they reside in a remote database created in HypcrTIES. 

The technical issue of non-textual data also has a market component. Not 
only do standards for various data types evolve separately, but the 
markets for the underlying technology in hardware and software 
progress at their own speed. Of particular importance, there is often a 
succession of dominant applications within a media type. For instance, on 
the Macintosh, MacPaint was surpassed in turn by SuperPaint and 
PixelPaint. A standard must accommodate this process in two ways. First, 
it must not bind data tightly to its creating application, in order that the 
user may replace it with another at a later date. Second, the standard 
must be extensible, to allow vendors to compete on features without being 
required to abandon the standard. 

Another market phenomenon is the decline of the so-called "integrated 
application." The required feature set within each data type has become 
so large that a project or product which attempts to do all becomes 
impractical. Integrated applications linger only at the novice level. 
Much integration is now done by cut-and-paste or data piping facilities at 
the operating system level. 

Hypertext may be viewed as the next logical evolution of integrated 
applications, with the ability to freely browse between all data types. 
Given the issues outlined above, it follows that the hypertext facility will 
need to be implemented at the system level to be effective. A successful 
standards effort must then include platform vendors and provide a 
mechanism for their joint efforts. 

The hypertext market is quite young. Many of the software vendors are 
startup ventures and are thin on capital and engineering resources. A 
successful standard must address this problem by making 
implementations available to such developers at very low cost. Failure to 
do this would confine use of the standard to high-end markets where 
firms and clients can afford the engineering overhead to implement the 
standard. It would also cut the standard off from the most innovative 
sector of the software market. Even a low cost standard must present 
convincing advantages in integration, power, and room for growth if 
developers are to give up proprietary schemes of data storage. 

4. Design Principles for a Hypertext Standard 

What principles can be deduced from these technical and market 
constraints? First, a standards effort must start with the creation of an 
abstract model of hypertext which is as inclusive as possible. Because 
many existing hypertext systems were tightly driven by application 
scenarios, this means looking at a variety of user communities needs. 
Particularly, building any system architecture driven by the needs of one 
application area into a standard would be inadvisable. The work of the 
Dexter Hypertext Model is a useful precedent in this area [Halasz 90]. 

Any standard must be portable to the greatest extent, not dependent on 
particular processor, display, network, or peripheral architectures. 
Portability will allow the greatest degree of interoperability in the 



-193- 



current computing environment, and guarantee survivability onto 
succeeding generations of technology. 



Given the need to incorporate existing data type standards and allow the 
implementing software to evolve independently, a hypertext standard 
must support modularity. Data items may be incorporated by reference to 
an existing file as well as by inclusion within a standard form hypertext. 
Extensions to existing standards to incorporate hypertext features should 
be minimal. 



A hypertext standard must be extensible to support the rapid evolution of 
both data type specific software and notions of usage of links. Any typing 
mechanism built into the hypertext definition must be open to extension. 
Methods must be provided for superseding one representation of a data 
element with another without disrupting the entire hypertext. Facilities 
must be provided for incorporating proprietary data representations with 
the facility to point at parallel standard representations. 



T 



179.82 



179.82 



179.82 



179.82 



179.82 




rflta,i»,g,feg«ign. 
tot jtitg,fttft.nig.atit..:tff..iw.»fft)> a. 















A 


_B 


1 


179.82 


179.82 


2 


179.82 


179.82 


ii 


179,82 


179.82 











^ entities can move 
between documents and 
stili be editable 

♦ documents can move 
between machines and 
link adaptively 



itssdsseaBL, 
to han.^. )> 



1 A 


B 




179.82 


179.82 


2 


179.82 


179.82 




179.82 


179.82 



/ (missing / 
^ picture) ^ 



Figure 5. Separability: Moving data around 



A principle termed "separability" is important to coexistence with today's 
file and network systems. This entails, first, a level of data organization 
called "entities." An entity encapsulates sufficient data and metadata that 
it may be moved or copied between files without loss of information. For 
instance, an animation data entity might contain a series of frames, 
persistent selections for linking, a color lookup table (GLUT), and a 
description of the required screen resolution and depth and processor 
resources. This could be moved in its entirety, while copying the frames 
alone would lose information as they were moved out of context. Figure 5 
illustrates this concept, as well as the related feature that entities must be 
robust in the face of missing linked data. In the partial hypertext 
extracted to a remote machine the library image is missing, but sufficient 



-194- 



layout information remains to block out its location and allow work to 
proceed. 

Separability must be supported with identity and inspectabilily. A robust 
identity mechanism allows an implementing system to detect if a 
referenced entity is missing or present in duplicate. Note that identity 
may be separated from the particular mechanism which a system uses to 
find the referenced entity. Various implementations might keep merged 
databases of entity identity vs. location, or resolve references using 
heuristic mechanisms peculiar to a platform. 

Inspectabilily means that the interdependencies of entities must be 
apparent to a utility which understands the linkage standards only, and 
has no knowledge of the internal structure of data entities. Such a naive 
utility may then copy or move portions of the hypertext without a need 
for extensions as new entity types are added. 

To allow room for the evolution of hypertext technology, a layered 
standard will be necessary. To permit layering, each portion of the 
standard must be policy neutral. This means that it must allow a wide 
range of choices in how it is applied by higher layers. For instance, a 
standard which specified link formats and also required their storage in a 
single "web" would not be neutral, because it enforces a particular 
implementation. A policy neutral formulation would specify the format 
and possibly behavior of links without specifying in what place(s) they 
must be stored. Policy neutrality also permits the delegation of certain 
design choices to implementors, and provides degrees of freedom for 
technical issues with no current solution. These issues include the 
division of entities and linkage information between files, link typing 
and usage, searchability and version management. Again, an abstract 
model is helpful in creating the generalizations needed for policy 
neutrality. 

Standards may be expressed as data formats or as behaviors. A hypertext 
standard expressed as an explicit data format is probably necessary to 
support environments where only serial ASCII or binary data is available. 
This is typical of the bulk transfer of reference hypertexts between 
machines. However, such a format is poorly adapted for update and 
search. Neutrality of applications is better provided by standardization at 
the behavioral level of an application program interface (API). A 
compliant implementation might simply provide access to the standard 
serial hypertext form, but would more likely implement a random access 
or object-oriented filing mechanism adapted for its particular platform. 
The distributed open hypertext environment is then implemented as 
peer-to-peer conversations among compliant implementations of the 
standard. 

5. Conclusions 

Standards must be approached cautiously in a field as new as hypertext. 
While we may need interim or experimental specifications for particular 
application areas, making the exchange of static hypertexts the subject of 
a standard is undesirable. Decisions which we make will necessarily 
affect other areas such as multimedia and compound documents. A 



-195- 



premature standard could have the effect of ghettoizing a subset of 
hypertext. The goals of a hypertext standard should be the 
implementation of the vision of distributed hypertext within an open 
systems framework. 

6. Acknowledgements 

This paper is based on extensive discussions with Jerry Morrison and 
Richard Moore, my colleagues at Apple Computer, and was also influenced 
by members of the Dexter Hypertext Workshops, particularly Norm 
Meyrowitz, Randy Trigg, Amy Pearl, Frank Halasz and Mayer Schwartz. 

7. Bibliography 

[Halasz 89] Halasz, Frank, et. al., "Panel: Confessions — What's Wrong with 
our Systems," given at Hypertext '89, November 5-8, 1989, Pittsburgh, PA. 

[Halasz 90] Halasz, Frank and Mayer Schwartz, "The Dexter Hypertext 
Model," to be presented at NIST Hypertext Standards Workshop, January 
16-18, 1990, Gaithersburg, MD. 

[Nelson 80] Nelson, T., "Replacing the printed word: A complete literary 
system," Proceedings of IFIP Congress 1980 . North-Holland, 1013-1023, 
1980. 



-196- 



Toward a Reference Model for Hypermedia 
H. Van Dyke Parunak 
Industrial Technology Institute 
P.O. Box 1485 
Ann Arbor, MI 48106 
(313) 769-4049, van@iti.org 
7 December 1989 

Abstract 

A necessary first step in discussing standardization in a domain is the development of 
a reference model for that domain, a high-level framework within which specific topics 
for discussion can be defined and discussed. This paper offers a "straw" version of such 
a framework as a basis for discussion, and discusses the "standardizability" of various 
detailed subjects within that framework. 

1. Introduction 

A reference model is a high-level description of a domain within which discussion of 
more detailed subjects can be situated. As a mechanism for setting the context of a 
domain, reference models have been useful in several fields. This section gives examples 
of other reference models, suggests some of the uses to which they may be put, discusses 
why a reference model is desirable for hypermedia, and outlines the high-level structure 
of a proposed reference model for hypermedia. 

1.1. Examples of Other Reference Models 

Reference models have been proposed in many domains, including telecommunications, 
factory control architectures, and material handling architectures. 

Perhaps the best known reference model is the ISO-OSI seven-layer model for 
telecommunications. [DAY83] By articulating the various communications functions and 
defining an ordered relation among them, this model has supported a vigorous and 
productive standardization effort. 

A number of studies have proposed reference models for manufacturing control; 
[PARU87] provides a useful summary, and [BIEM89, \VILL89] are more recent 



-197- 



treatments. These studies have been motivated by the growing interest in integrated 
manufacturing, and the resulting need to relate the various entities in a manufacturing 
enterprise to one another in a consistent way. 

In the domain of material handling, the OSI model has been adopted to define a 
layered model for the transport of material, [PARU88| and this model has been used as 
the basis for experimental implementations in our laboratory. 

1.2. The Uses of a Reference Model 
A reference model is useful for description, standardization, design, and innovation. 

It provides a descriptive framework for comparing existing systems in its domain, and 
in fact is often compiled by surveying existing systems for similarities and differences. 
_ It thus provides an underlying ontology of its domain. 

By identifying the critical subjects in the domain and showing how they are related to 
one another, it provides a context for standardization. It facilitates discussion of what is 
and is not ready for standardization, identifies specific subjects for standards, and calls 
out where subsystems (and thus the standards that describe them) must interface with 
one another. 

As a high-level analysis of its domain, a reference model guides the designer of a new 
system in identifying the Issues that must be addressed and the broad functions that the 
system must provide, as well as suggesting the kinds of solutions that have been 
attempted in the past. 

Reference models not only help to mature a field through development of standards 
and common analyses, but can also foster innovation. At the detailed level, by 
partitioning the problem, they invite the development of new solutions, showing what 
has already been tried. At a higher level, they invite creative thinkers to challenge their 
overall structure and thus introduce new paradigms. 



-198- 



The descriptive and prescriptive functions of a reference model are in natural and 
unavoidable tension. As a guide to classifying existing systems and as a pointer to 
needed innovation, a reference model should be as comprehensive as possible, able to 
embrace any implementation of the domain. As a roadmap for standardization or a 
guide for designers, it should embody design choices that reflect good practice and 
sound engineering, and thus be selective. It seems reasonable to expect that reference 
models will follow a life-cycle that moves from broad and descriptive to selective and 
prescriptive. While it may be premature to build prescriptive models of hypermedia, it 
is not at all too early to formulate broad descriptions of the underlying technologies, 
descriptions that through time can evolve into more selective models. 

1.3. Why a Reference Model for Hypermedia? 

A reference model for hypermedia is desirable not only for helping the technology to 
mature, but also for fostering its development as a distributed tool. 

Every worker in a domain has an individual "reference model" of that domain within 
which various contributions to the field are implicitly classified and assessed. A textbook 
in a domain is essentially an instantiation of such a model, and helps newcomers to the 
domain to put in place a mental framework within which to operate. The rapid growth 
of interest in hypermedia makes this educational service particularly desirable in the 
case of hypermedia. However, if this were the only motive, it is questionable whether a 
joint activity to develop such a model would be justified. 

The need for a jointly developed model arises from the potential of hypermedia as a 
distributed technology. Hypermedia is distributed in at least two ways. First, it has 
proven to be a useful medium for managing the collaboration of teams of 
workers. [CONK87, HALA87] Thus it is often implemented as a distributed application, 
with the resulting need for standards to insure that the various components of such an 
application are consistent with one another and can be maintained in a modular 
fashion. This motive for standardization becomes especially strong when the components 
are not operating in a homogeneous environment. Second, the information that is linked 



-199- 



together in a hypermedia system is often distributed in the sense of being of differing 
types and origins. The ability of a hypermedia system to access generic materials 
without expensive recoding and preprocessing will depend on the rapid development and 
broad dissemination of standards for the production and encoding of machine-readable 
information. 

1.4. A Possible High-Level Structure 

The reference model sketched in this paper is described from three perspectives: the 
functional elements of a hypermedia system, implementation concerns, and interface 
issues. We will outline the main elements to be considered in each of these areas, and 
also suggest the applicability of standards to each area. 

2. Elements of Hypermedia 

The two basic elem.ents of a hypermedia system are nodes of information and links 
that join them together. In addition, recent research suggests that the usability of 
hypermedia depends on the disciplined use of structured composites of nodes and links 
as higher-order entities. 

2.1. Nodes 

The nodes of a hyperbase are the units of information that it assembles together and 
among which it provides ready movement. The nodes in a system can be described 
from the perspective of their contents, their typing, and their structure. 

2.1.1. Node Contents 

The very name "hypertext" suggests that virtually every hypermedia system can 
present information in the form of text. Most implementations support some form of 
graphic display as well. Animation, video, and audio are less common but have been 
demonstrated. [BIEB89] suggests generalizing the notion of a node to "any information 
item about which the system can reason." Such a definition permits a node to be 
executable code that is invoked when the link leading to it is traversed, thus leading to 
any conceivable kind of computer operation. In fact, some early antecedents of 
hypertext were menu systems, in which all leaf nodes were of this sort. 



-200- 



As long as nodes are treated as atoms, there is no difficulty with such a variety of 
node contents. For many purposes, one must define locations within nodes, either as 
destinations or as origins for a link. The mechanisms for such definition are highly 
dependent on node contents. For example: 

• Because text is one-dimensional, location in a textual node is conveniently 
defined on the basis of characters. 

• In graphical nodes, location is defined two-dimensionally on the basis of 
pixels. 

• Animation and video invite the same pixel-based definition of location as 
does graphics, but there is an additional time dimension. 

• Location in an audio node is most readily defined temporally. 

• In a node consisting of executable code, the instruction counter is a 
reasonable measure of location. If the node processes user input, location can 
be defined in terms of the possible user trajectories through the program. 

2.1.2. Node Typing 

In addition to different contents, nodes may also have different types. Node typing is 
most often important in the context of typed links. For instance, in gIBIS, a Supports 
link can only appear between a node of type Argument and one of type 
Position.[CONK87] Together with link typing, node typing permits the definition of a 
grammar or rhetoric over a hyperbase, and greatly facilitates user navigation and 
automatic information retrieval. 

2.1.3. Node Structure 

The measures of location defined above for nodes of differing contents are sometimes 
too primitive for convenient use. For example, one can define words or sentences in a 
textual node, buttons or sliders in a graphical node, musical phrases in an audio node, 
or positions in a user trajectory in an executable node, hiding the corresponding 
characters, pixels, time intervals, or instruction counts as implementation details. Then 
links can originate or terminate at these higher-order objects. Consistent definition of 
such higher-order objects and their mappings to lower-order entities offer a good 
opportunity for standardization. 



-201- 



2.2. Links 

A discussion of links in a hypermedia system requires definition of directionality, 
topology, types, anchors, and modes. 

2.2.1. Link Directionality 

A link is directional if its ends are differentiated in some way from one another. 
Often, the mechanism for traversing a directional link in one direction is different from 
that used in the other direction. For instance, links in Intermedia are not directional. 
The same icon marks both ends of the link, and the same operation traverses it in both 
directions. In HyperTies, links are directional, and the backward direction is usually 
only accessible if one has already traversed the link in the forward direction. 
Cognitively, directional links can be a valuable aid to navigation in a 
hyperbase.[PARU89] 

2.2.2. Link Topology 

Current systems typically do not constrain the overall topology that links can form, 
but user navigation depends critically on this topology, and there are strong cognitive 
motives for disallowing arbitrary topologies. [PARU89] The number of possible 
topologies is countably infinite, but important major classes are linear, hierarchical, 
hypercube, and DAG. 

2.2.3. Link Types 

By defining various types of links (and typically correlating them with typed nodes), 
we can enrich the rhetorical capabilities of a hyperbase, as discussed above under "Node 
Types." 

2.2.4. Link Anchors 

The anchors, or endpoints, of a link are its origin and its destination. The destination 
of a link can either be a node as an atomic unit, or some entity contained within the 
node. In the case of a structured node, this entity will be some element of the 
structure. In the case of an unstructured node, this entity will be either a point or a 
region defined by whatever measure of location is appropriate to the node's contents. 



-202- 



If links are constrained to originate wit?i nodes as atomic units, the resulting 
hyperbase will have a linear topology, which forfeits the more interesting features of 
hypermedia. Thus at least the origins of links are some element within a structured 
node or some location or region within an unstructured node. 

2.2.5. Link Modes 

The simplest form of a link is a fixed connection between two anchors (either nodes or 
entities within nodes). The order of processing a link is usually select-traverse-display. 
Both the form and the processing of a link can be expanded [BIEB89]; a link can be 
virtual (computed at run-time) rather than fixed, and inferencing can be added both 
before and after link traversal. Such additional inferencing can be used to implement 
such modes of linking as warm links (in which users can push or pull data over a link) 
and hot links (in which data modified at one end of the link is automatically updated 
on the other end).[CATL89j 

2.3. Composites 

There has been a growing realization among workers in hypermedia that usable 
hyperbases require the ability to manipulate composite entities: entities that are larger 
than, and made up of, individual nodes and links. [HALA87] Such composites can be 
defined either rhetorically or topologically. 

Paths [ZELL89] are a simple example of a topological composite. A bare network of 
links and nodes is well-suited to random browsing, but many applications of 
hypermedia presuppose a basic trajectory through the hyperbase, with the rest of the 
material available as needed. Paths support such applications by giving writers a way to 
define a backbone that readers should follow, and to which they can readily return after 
any digressions. Topologically, the path imposes a linear topology on a much more 
complicated network, thus combining the cognitive advantages of the simpler topology 
with the fiexibility of the more complex one. 

Rhetorical composites are specific constellations of (usually typed) nodes and links 
that form a logical unit for manipulation and navigation. For example, the Toulmin 



-203- 



argumentation schema [TOUL69, STRE89] represents an argument as a composite of 
nodes that articulate a claim, its supporting datum, the warrant and backing that make 
the datum relevant to the claim, and any rebuttal. Derivatives of IBIS such as gIBIS 
focus on the basic tree consisting of an issue, various positions on that issue, and the 
arguments for and against each of the positions. [CONK87| 

2.4. Element Standardization 

The elements that we have discussed form the ontological foundation of hypermedia, 
suggesting that at least common terminology needs to be defined if standardization of 
any aspect of hypermedia is to be possible. This basic ontology is stable enough that the 
outlines of a reference model constructed now will probably be able to accommodate 
new techniques as they are developed, by adding subpoints as appropriate. 

3. Implementation Concerns 

Here we address both architectural and programming issues. 

3.1. Layered Architecture 

Architecturally, there is a growing consensus in favor of the value of a layered 
architecture for hypermedia. This approach has been applied both to data 
communications [DAY83] and the control of material handling [PARU88]. It not only 
permits modular, maintainable programs, but also facilitates access of a layered system 
by other systems that know the services published at each layer. Thus a layered 
architecture facilitates the development of hyperbases that can interact with one 
another as well as with users. 

At least four layers are useful for a layered hypermedia architecture: data, element, 
inference, and interface. 

3.1.1. Data 

The data layer provides consistent data management for all information in the 
hyperbase, including both the contents of nodes and the links among nodes. If 
development and browsing of a hyperbase are to be separate processes, this layer 



-204- 



manages access permissions to implement read-only networks. In a multiuser 
hyperbase, this layer must support multiple access with appropriate consistency 
management. Many applications will require it to support versioning as well. As 
hypermedia becomes more widely applied, distributed hyperbases will develop that will 
require the data layer to provide distributed data access, and in this case it would 
logically be defined as an RDA application on top of an OSI stack. 

3.1.2. Element 

The element layer provides separate services for managing nodes and links, and 
translates the raw data of the data layer into these atomic elements of hypermedia. The 
value of storing links separately from nodes is becoming evident, and is supported in 
Intermedia and in the link service furnished with Sun's Network Softv/are 
Environment. [PEAR89] Among other benefits, this separation permits users to have 
private sets of links on a document, links that are not visible to other users. The link 
service needs to be able to combine different sets of links over a single document so that 
a user perceives them as forming a single set. Composites can be supported by 
appropriate internal recursion, thus permitting composites of any degree of nesting to 
be defined. 

3.1.3. Inference 

The inference layer provides at least the ability to traverse a link and retrieve the 
node at the destination. It is also a reasonable place to house services that do inference 
on source and destination nodes in conjunction with link traversal to support 
generalized link traversal as defined in [BIEB89]. 

3.1.4. Interface 

The interface layer defines the mechanisms through which the user interacts with the 
hyperbase, and is responsible for displaying the information contained in the node. 



-205- 



3.2. Programming fesiies 

Object-oriented programming has been an important supporting technology for 
hypermedia, and the development of standards for OOPS will facilitate the interaction 
of various hypermedia systems. 

Some systems, such as HyperTies [COGN89], HyperPAD [BRIG89], and HyperCard 
[WILL87|, build nodes as a stack of different objects, A typical series of such objects 
includes the background, page, field, and button. If nodes are to be accessed through 
, multiple systems, standardization of node architecture is necessary. 

3.3, Implementation Standardization 

Implementation standardization is necessary if hypermedia systems are to interoperate 
(for instance, by accessing the same information). A layered architecture offers promise 
as the reference model for such standardization. Outside of the hypermedia community, 
standardization in object-oriented languages and environments will greatly advance the 
foundation on which hypermedia systems rest. 

4. interface Issues 

There are two main categories of interface issues in hypermedia: those concerned with 
constructing links among nodes, and those concerned with browsing a completed 
network. While manj^ commercial systems include facilities for generating the contents 
of nodes, this process is so application-dependent that it seems to fall outside the scope 

of a reference model, 

4.1. Building Links 

Constructing the links is the most laborious part of populating a hyperbase. Three 
main sets of techniques are commonly used: automatic, mark-up and point-and-shoot. 

4.1.1. Automatic Linking 

Information retrieval (IR) techniques can be used to build networks automatically, for 
example, linking together all (textual) nodes containing a specified string of characters. 
Because these techniques are purely syntactical and do not "understand** the text, they 



-206- 



must usually be supplemented by manual review and revision to eliminate spurious 
linkages and to add links that the syntactical scan misses. Natural language techniques 
from AI are beginning to improve the effectiveness of automatic linking, but still are 
not able to "understand" a text and so cannot completely eliminate manual 
editing. [HA YE88] Applied in real time, these techniques are a common way to 
implement virtual links. Standardization of IR techniques is marginally useful for the 
construction of links before run-time, since manual editing can correct any errors, but 
will be useful when these techniques implement virtual links, to insure consistent 
operation of such links across various implementations. 

4.1.2. Mark-Up Linking 

Many PC-based systems require manual mark-up with a text editor to identify link 
sources (and sometimes destinations). The most simple systems simply enclose link 
anchors in reserved brackets, which on execution are interpreted by the display manager 
and result in modified display attributes for the anchor. A more complex mark-up 
system, such as those conforming to [IS086], provides a rich language for specifying 
functional components of a document, such as paragraph and chapter headers. While 
these mark-up languages are not originally designed for hypermedia, they provide a 
useful mechanism for facilitating automatic linking. 

4.1.3. Point-And-Shoot Linking 

The most sophisticated manual linking systems (for example, [PEAR89]) use a point- 
and-shoot interface that permits the user to point at the entities to become anchors and 
thus generate links directly. 

4.2. Browsing 

Browsing issues include the form and manipulation of the display, and navigational 
mechanisms. 



-207- 



4.2.1. Display 

One area of active discussion in the hypermedia community is whether information 
should be divided into screen-sized chunks or "cards," or whether the screen should be 
treated as a window that moves over a larger unit of information. There appear to be 
applications where each approach is superior, and both should be accommodated in a 
reference model. 

A number of issues concern the mechanics of manipulating the screen. For instance, 

» In a scrolling system, does one push the window up over the information, or 
does one push the information up past the window? 

• How does one select a link origin? 

® Hov/ are active and inactive buttons represented on the screen? 

• What is the correspondence between mouse action and cursor keys? 

The Macintosh has provided a de facto standard for many of these issues. While 
standards are highly desirable (especially for users who must move from one platform to 
another), they are probably best handled in the broader CHI community, not by 
hypermedia specialists. 

4.2.2. Navigational Mechanisms 

Navigational mechanisms are of two main types: maps and path macros. 

4.2.3. Maps 

A map is a single display that shows nodes in abbreviated form (often as icons) and 
displays the links among them. While intuitive, a map can become cluttered and 
relatively useless for large, complex systems unless it is selective. For instance, a map 
displaying only links of a certain type and their associated nodes, or only composite 
nodes and not their components, will be simpler than a complete map. 



-208- 



4.2.4. Path Macros 

A path macro is a composite that is generated in real time by gathering together 
nodes that the user has visited and the links along which they were visited, at least up 
to some limiting topology. For instance, a linear topology is commonly used to generate 
a backup stack. A path macro permits the user easily to revisit nodes that have been 
seen and are of particular interest. 

4.3. Interface Standardization 

Interface standardization is desirable, especially for people who must use more than 
one platform on a regular basis. Much of the desired standardization here will come not 
through work specifically in hypermedia, but through broader forums in CHI. 

5. Conclusion 

Hypermedia, especially in distributed applications, will benefit from standardization. 
To facilitate developing such standards, this paper has suggested a high-level reference 
model that describes the elements, implementation concerns, and interface issues for 
hypermedia. In the area of elements, the greatest need for standardization is in 
vocabulary. Implementation offers a rich possibility for standardization in the 
development of a layered model for hypermedia, and will profit from OOPS 
standardization being pursued elsewhere. Most of the interface standardization that is 
possible at this point is being pursued in the broader CHI community, and (apart from 
navigational devices that are particular to hypermedia) should not be the focal point of 
standardization efforts by the hypermedia community. 

References 

[BIEB89) M. Bieber and S.O. Kimbrough, "On Generalizing the Concept of 

Hypertext," Boston College Computer Science Department Technical 
Report BCCS-89-03, 1989. 

[BIEM89] F.P.M. Biemans, "A Reference Model for Manufacturing Planning 

and Control," Ph.D. Dissertation, University of Twente, 1989. 

[BRIG89] HyperPAD Users Guide, Brightbill-Roberts & Co., Ltd., Syracuse, 

NY, 1989. 



-209- 



[CATL89] 



T. Catlin, P. Bush, and N. Yankelovich, "InterNote: Extending a 
Hypermedia Framework to Support Annotative Collaboration," 
Proceedings of Hypertext '89, 365-378. 



[COGN89] Hyperties Author's Guide, Cognetics Corporation, Princeton Jet., NJ, 

1989. 

[CONK87] J. Conklin and M.L. Begeman, "gIBIS: A Hypertext Tool for Team 

Design Deliberation," Proceedings of Hypertext '87, 247-252. 

[DAY83] J. Day and H. Zimmermann, "The OSI Reference Model," 

Proceedings of the IEEE, 7 (December 1983), 1334-1340. 

[HALA87] F.G. Halasz, "Reflections on NoteCards: Seven Issues for the Next 

Generation of Hypermedia Systems," Proceedings of Hypertext '87, 
345-366. 



[HAYE88] 



[IS086] 

[PARU87] 

[PARU881 

[PARU89] 
[PEAR89] 
[SMOL87] 



P. Hayes, L.E. Knecht, and M.J. Cellio, "A News Story 
Categorization System," Proceedings of the Association for 
Computational Linguistics Conference on Applied Natural Language 
Processing, 1988. 

International Standard ISO 8879: Information processing ~ Text 
and office systems ~ Standard Generalized Markup Language 
(SGML), 1986. 

H.V.D. Parunak and J.F. White, "A Synthesis of Factory Reference 
Models," Proceedings of the IEEE Workshop on Languages for 
Automation, Vienna (August 1987), 109-112. 

H.V.D. Parunak and R. Judd, "LLAMA: A Layered Logical 
Architecture for Material Administration," International Journal of 
Computer Integrated Manufacturing 1:4 (1988), 222-233. 

H.V.D. Parunak, "Hypermedia Topologies and User Navigation," 
Proceedings of Hypertext '89, 43-50. 

A. Pearl, "Sun's Link Service: A Protocol for Open Linking," 
Proceedings of Hypertext '89, 137-146. 

P. Smolensky, B. Bell, B. Fox, R. King, and C. Lewis, "Constraint- 
Based Hypertext for Argumentation," Proceedings of Hypertext '87, 
215-246. 



-210- 



[STRE891 



N.A. Streitz, J. Hannemann, and M. Thuring, "From Ideas and 
Arguments to Hyperdocuments: Travelling through Activity Spaces," 
Proceedings of Hypertext '89, 343-364. 



[TOUL69] 



S.E. Toulmin, The Uses of Argument, Cambridge University Press, 
1969. 



[WILL87] 
[WILL891 



G. Williams, "HyperCard," Byte, 12:14 (December 1987). 

T.J. Williams, Editor, A Reference Model for Computer Integrated 
Manufacturing (CIM), Instrument Society of America, 1989. 



[ZELL89] 



P.T. Zellweger, "Scripted Documents: A Hypermedia Path 
Mechanism," Proceedings of Hypertext '89, 1-14. 



-211- 



An Interchange Format 
for Hypertext Systems: 
the intermedia Model 



Victor A. Riley 



Institute for Research in Information and Scfiolarship (IRIS) 
Box 1946 
Brown University 
Providence, Rhode Island 02912 



ABSTRACT 

I Realization of the potential for information sharing 
that is inherent in hypertext systems depends on the 
ability to readily exchange data between those sys- 
I terns. A format for exchanging link-related data be- 
] tween first-order hypertext systems has been de- 
I signed, and partially implemented, for the 
; Intermedia system. The design is described to the 
i individual field level. An example of usage for 
Intermedia link-related information is provided. 
The import, export, and verification utilities cre- 
ated for the interchange format are also described. 

i 1. INTRODUCTION 

I The concept of hypertext has been around for several 
decades and recently we have seen the advent of 
||j several hypertext applications and systems. These 
i applications allow one to create text, graphics, ani- 
; mation, video, and a number of other data types and 
3 proceed to link them together in any manner one sees 
j fit. One capability that is still missing is the abil- 
|| ity to transfer a set of hypertext links and docu- 
ments from one system to another. Such a capability 
1 would open the door to sharing information and 
bring us one step closer to the mythical 
i "hyperspace" or "docuverse" [NelsSl] as Nelson has 
■ termed it. This paper examines a format for allow- 
I ing interchange between hypertext systems. 

2. PURPOSE OF THE INTERCHANGE FORMAT 

j Although a wide variety of hypertext/hypermedia 
'j systems exist today, they can be placed into one of 
two categories. 

A first-order hypertext system manipulates the data 

' of 

i • documents 



• anchors within documents 

• links between anchors 

• some standard attributes associated with docu- 
ments, anchors, and links. (The standard at- 
tributes include the name, creation time, and cre- 
ator of a document, anchor, and link.) 

Most hypertext systems in existence today are at 
least first-order hypertext systems [Conk87]. 

A second-order hypertext system manipulates all 
the information a first-order hypertext system con- 
tains with the additional support for 

• user-defined objects and types 

• user-defined attributes and keywords 

• version history for documents, anchors, links, 
and attributes 

There are only a few second-order hypertext systems 
in existence or development today: Engelbart's 
NLS/ Augment [Enge68], Tektronix's Hypertext Ab- 
stract Machine [Camp88], and Nelson's Xanadu 
[Nels81]. 

Regardless of these categories, all hypertext sys- 
tems need to store this persistent link data in some 
form of database. Since database formats and data- 
base files are inherently nonportable, a portable in- 
terchange format must be designed to facilitate ex- 
changing sets of link-related hypertext data (what 
would be called webs in Intermedia). 

Our interchange format contains the essential link- 
related information for a first-order hypertext sys- 
tem. Any application or system that understands the 
interchange format — what we call here a partici- 
pating application or system — can capture all the 
existing hypertext link information as it exists in 
some other participating hypertext system. In con- 
junction with methods for converting and transferring 
document data, this capability makes possible the 
the complete sharing of information between hyper- 
text systems, largely fulfilling the "docuverse" 
ideal. 

The interchange format is useful for transferring 
data between similar first-order hypertext systems. 
It may also be useful for transferring first-order hy- 
pertext information into a second-order hypertext 
system or vice-versa. Suitable defaults could be sup- 
plied for the extra information necessary to trans- 
form first-order information into second-order; when 
transferring second-order information into firiit-order, 
the extra information could be ignored. 

It needs to be stressed that the application-specific 
contents and format of hypertext documents them- 



-213- 



selves are outside the scope of the interchange for- 
mat (which is concerned with the links between the 
documents) and of this paper. Data exchange on the 
document level is approached in other ways, com- 
monly bv adherence to a file format standard, such 
as PICT/TIFF, MacPaint, or RTF. 

3. THE INTERCHANGE FORMAT 

3.1 The Basic Objects 

The information that most hypertext systems deal 
with is basically the same, although the names of 
objects may differ slightly from one system to the 
next. A first-order hypertext system deals with doc- 
uments, anchors, links, and system attributes. These 
objects are stored in a database that the system's 
subordinate applications access in order to provide 
linking functionality. In the interchange format, 
each of these objects corresponds to a separate data 
file that contains the information specific to all oc- 
currences of that object in the system. The architec- 
ture of these files is described in the next section. 

Documents are the containers for the application- 
specific information in the hypertext system. They 
are built up of two components: the actual applica- 
tion-specific contents of the document (the informa- 
tion the user is interested in working with), and the 
information necessary for the application to render 
its views. The contents could be in the form of text, 
graphics, audio, video, etc. 

Anchors are the locations in documents to which 
links are attached. Some examples of anchors are 
spans of text, graphical objects, audio or video, or 
bitmaps. Anchors are application-specific in that it 
is the application, not the hypertext system's 
database, that must render the anchor (e.g., in doc- 
ument views). 

Links are the connections between anchors. They are 
directional in that they have a source and destina- 
tion anchor. Applications can enforce bidirectional- 
ity or directionality by giving equal precedence to 
both source and destination, or keeping the distinc- 
tion. 

System attributes are predefined attributes that are 
associated with documents, anchors, and links. For 
all first-order hypertext sj^stems, these consist of 
the name, creator, and creation time. Intermedia 
adds the modifier and last modification time to the 
standard system attributes. 

User-defined attributes are also associated with 
documents, anchors, and links. They allow for flexi- 
ble processing and retrieval of hypertext informa- 
tion. 



3.2 Architecture of the Data Files 

The interchange format consists of five data files for 
recording information about the link-related objects 
in the participating hypertext system, and one file 
for each document in the hypertext system. 

document information /i7e 

The document information file contains general in- 
formation dealing with all hypertext documents 
stored in the participating system. This information 
allows an application to gain access to the physical 
location of a document, get the user-defined access 
rights associated with the document, and retrieve 
information about the creator and last modifier of 
the document. A unique identifier for the document 
enables access to anchor information stored in the 
anchor file (described below). 

anchor file 

The anchor file contains information about all an- 
chors in all documents in the hypertext system. This 
information allows an application to know where an 
anchor is located, who created and last modified 
the anchor, and other information that may be 
needed (e.g., to render a view of the anchor). A 
unique identifier for the anchor enables access to 
link information stored in the link file (described 
below). 

link file 

The link file contains information about all links be- 
tween all anchors in the hypertext system. This in- 
formation allows the system to traverse hypertext 
links. The file also contains information about the 
creator and last modifier of the link. A name and 
unique identifier for the link are provided, for con- 
sistency with the other files, and to allow for future 
expansion of functionality. 

attribute definition file 

The attribute definition file contains information 
defining the attributes and keywords used in the 
system. Predefined (system) attributes such as name, 
creator, modifier, creation time and modification 
time, are not defined in this file. 

attribute file 

The attribute file contains information about which 
objects have which attributes attached to them, as 
well as the values of those attributes. 



-214- 



document //7es 

The format of each document file is determined by 
its contents, and the requirements of the participat- 
ing application in which it is used. Formats cur- 
rently employed in Intermedia include "web," for- 
matted text, structured graphics,, timeline, and 
bitmap image. As noted above, the exchange of this 
information between systems is not intended to be 
part of the interchange format. However, several 
fields in the five link-related files are indirectly 
dependent on the existence, system attributes, or con- 
tents of the document files. These are described un- 
der "Implementation." 

3,3 Impiementation 

This section describes the interchange format at the 
level of data formatting and field definition. 
Examples illustrating these descriptions are pro- 
vided in Section 4. 

Data Formatting 

In order to make the interchange process as straight- 
forward as possible, the format of the data to be ex- 
changed is kept simple 

Each value is stored in normal ASCII format, so 
that it is easily readable, editable, and portable. 

Each data record in a file is delimited by a car- 
riage-return/linefeed character pair. Each data 
field in a record is delimiled by a tab character. To 
avoid conflicts, the tab character is not permitted in 
document and path names. 

Data values are either strings or numbers. String 
values can be any length. Numeric values are four 
full bytes; the decimal ASCII digits correspond to an 
unsigned 32-bit long word. Certain numeric fields 
store information in terms of the bit patterns in the 
long woi'd. 

All numeric values that denote a time are stored in 
Unix GMT format, which expresses a time value as 
the number of "ticks" since an established starting 
point (midnight of January 1, 1970). There are about 
31.5 million ticks in a calendar year. 

Values for the predefined system attributes 
{creationTime, modTime, creator, modifier, and 
name) are obtained from the operating system via 
the Export udlity. 

Since some applications may require data not specif- 
ically identified in the interchange format, certain 
fields are allotted for this special purpose. Data in 
these fields is arbitrarily stored in string format, for 
maximum flexibility, and may need to be converted 



to some other data format for use by a target appli- 
cation. This feature allows for a variable number of 
data values and types to be transferred by the inter- 
change format. 

Site Identification 

The first field of each record contains a site-specific 
ID. This value is composed of a unique number for 
each site (or machine) using the interchange format 
and a site unique number for the database to which 
hypertext data is being imported or exported. The 
combination of a sitclD (with its "site" and 
"database" components) and an object's own unique 
ID allows the object to permanently maintain its 
identity across exchanges of data between sites. 

Some type of assignment of unique numbers for sites 
must be administered in order to implement this fea- 
ture fully. If this were not done, however, the re- 
mainder of the interchange format could still be im- 
plemented independently. 

Another uniqueness scheme might consist of combin- 
ing a 32-bit random number with two 16-bit random 
numbers, which would provide IDs for the site and 
the local database, respectively. This 64-bit number 
should be unique across the domain of all hypertext 
systems. 

Field Definitions 

document information file fields 

sitelD (Numeric) Unique identifier of the 

originating site and database.^ 

docID (Numeric) Unique identifier of a 

document. Assigned sequentially by 
the DBMS. 

docType (Numeric) Code specifying the 

document's type. 

Allows the system to identify the 
the correct target application for 
application-specific data.^ 



^The first short word of the value stores the site number; the 
second short word stores the database number. The interchange 
format stores the number resulting from reading the two short 
words as a long word. 

^Intermedia supplies codes for its currently supported document 
types (InterWord, InterDraw, etc.). Codes must be standardized 
for participating systems, be these numeric codes or string codes. 



-215- 



accessRights (Numeric) Number expressing the 
types of access allov/ed to the doc- 
ument for various groups of users.^ 

groupNarne (String) The name of the group 
identified in accessRights. 

creationTime (Numeric) Time the document was 
created, 

modTime (Numeric) Time the document was 

modified. 

creator (String) Name of the user that 

created the document. 

modifier (String) Name of the last user to 

modify the document. 

docName (String) Name of the document. 

Assigned by user when document is 
saved. 

path (String) Directory location of the 

document in the Unix tree, relative 
to the application's home direc- 
tory. 



anchor file fields 

siteJD 



(See description for document in- 
formation file.) 



anchorlD (Numeric) Unique identifier of an 

anchor; assigned sequentially by 
the DBMS. 

anchorDocID (Numeric) Value of docID, in the 
document information file, for the 
document containing the anchor 
identified by anchorlD. 

Allows system to determine the 
document in which the anchor is 
located. 

creationTime (Numeric) Time the anchor was 
created. 



modTime (Numeric) Time the anchor was 

modified. 

creator (String) Name of the user that 

created the anchor. 

modifier (String) Name of the last user to 

modify the anchor. 

anchorName (String) Name of the anchor. 

X-loc (Numeric) X, Y, and Z-axis coordi- 

nates of the anchor, within the 
document specified by docID. 

Y-loc These allow system to determine 

placement of anchor in document 
window. 

Z-loc Interpretation of coordinates is 

application-specific. 

appData (String) Application-specific infor- 

mation dealing with anchors. 

Allows participating application 
to obtain other information re- 
quired. Exam.ples might include 
data needed to render a type of 
window view. 

Values are separated by space 
characters, or other delimiters 
specified by the participating ap- 
plication. 



link file fields 

sitelD 

linkID 
linkType 



(See description for document in- 
formation file.) 

(Numeric) Unique identifier of a 
link; assigned sequentially by the 
DBMS. 

(Numeric) Code specifying the type 
of relationship between the link's 
two anchors. ^ 



^ The four bytes of the value, from high to low, correspond to the 
rights granted to: system administrator, owner, group, and world 
(all) users. The bits of each byte, from high to low, correspond to 
the following rights granted to each of the four user groups: 
change access rights for the document, write to the document, 
create links in the document, and view the document. The bits are 
set on or off in groups of two. 



srcAnchorlD (Numeric) Source anchor of. the 
link, as identified by the value of 
anchorlD, in the anchor file. 



intermedia supplies codes for its currently supported document 
link types. Codes must be standardized for participating systems, 
be these numeric codes or string codes. 



-216- 



destAnchorlD (Numeric) Destination anchor of 
the link, as identified by the value 
of anchorlD, in the anchor file. 

creationTime (Numeric) Time the link was cre- 
ated. 

modTime (Numeric) Time the link was modi- 

fied. 

creator (String) Name of the user that 

created the link. 

modifier (String) Name of the last user to 

modify the link. 

linkName (String) Name of the link. 

attribute definition file fields 

sitelD (See description for document in- 

formation file.) 

attDefID (Numeric) Unique identifier of an 

attribute definition; assigned se- 
quentially by the DBMS. 

attDefType (Numeric) Code specifying the at- 
tribute's type. ^ 

General-purpose flag value. One 
potential use is to specify what 
objects the attribute can be at- 
tached to. 

attName (String) Name of the attribute. 

attribute file fields 

sitelD (See description for document in- 

formation file.) 

attDefID (Numeric) Value of attDefID, in 

the attribute definition file. 

Allows system to look up the at- 
tribute's name and type. 



attValType 
attValue 



objectType 

objSitelD 

objectID 



This section 
can be used 
data from a 
Intermedia. 



(Numeric) Code specifying the 
data format of attValue.'^ 

(Variable format) Value of the at- 
tribute. Assigned by the user. 

The next three fields refer to the 
object to which the attribute is at- 
tached: (document, anchor, or 
link). 

(Numeric) Code specifying the ob- 
ject type (document, anchor, or 
link). 3 

(Numeric) Value of sitelD, in the 
corresponding file {document in- 
formation, anchor, or link). 

(Numeric) Value of the object's ID, 
in the corresponding file (document 
information, anchor, or link). 

4. EXAMPLE OF USE 

illustrates how the interchange format 
to create, store, and reuse link-related 
first-order liypertext system, namely 



4.1. Sample Data in Intermedia 



The Intermedia system is described in a number of 
articles, notably [Meyr86] and [Yank88a]. A public 
release of the software, with full documentation, is 
also currently available through IRIS and through 
the Apple Programmer and Developer's Association 
(APDA). This release (3.0) runs on the Apple 
Macintosh II, under version 1.1 of A/UX, Apple's 
version of Unix. 

Figure 1 shows the Intermedia desktop environment. 
Two elementary sample documents have been cre- 
ated, one in Iiitermedia's InterWord format, the 
other in InterDraw. For the clarity of the example, 
these objects have been created in an empty new 
Intermedia database. The folder window (labelled 
"/int/docs/demo") contains the icons representing 
the documents and the Web comprising the links be- 
tween them. The Web View window displays the 
linking structure. The information used in generating 



participating system supplies codes for its currently ^A participating system supplies codes for its currently 
supported attribute definition types. Codes must be standardized supported attribute value types. Codes must be standardized for 
for participating systems, be these numeric codes or string codes, participating systems, be these numeric codes or string codes. 

^A participating system supplies codes for the object types of 
document, anchor, and link. Codes must be standardized for 
participating systems, be these numeric codes or string codes. 



-217- 



this Web View is also used to generate the anchor 
and link files of the interchange format. 

An anchor has been created from the word "block" in 
the InterWord document (indicated by the arrow 
marker over the word). Another anchor has been 
created from the two rectangles in the InterDraw 
document. Each anchor can be assigned a name; the 
names are not shown here, but can be viewed and 
edited by the user by means of dialog boxes. 



The current version of Intermedia does not make use 
of attributes and keywords, so these are not repre- 
sented in the example. 

At the moment shown in the figure, the link be- 
tween the two anchors has just been followed, from 
the InterWord to the InterDraw document. This is 
shown by the shaded selection handles around the 
rectangles and the shaded link line in the Web 
View. 



^ File Edit Intermedia VnnX Arrange Print 




Figurel. Sample documents on the Intermedia desktop. Linking is indicated by the arrow markers in the doc- 
ument windows and the icon-connecting line in the Web View window. 



Intermedia allows users to edit the access rights to 
documents, through the use of the "Document 
Properties" dialog box (simple matrix of sixteen 
check boxes, not shown here). The ability to edit 
these rights is itself controlled by the rights 
scheme, with the system administrator having ul- 
timate control over a document's access. The rights 
for the two documents in this example are set so as 
to grant the system administrator, document owner, 
and members of the owner's "group" the right to per- 
form all operations on these documents; all other 
users (the "world") can only read them and make 
links in them. 



4.2. Sample Data in the Interchange Format 

This section illustrates how a current version of the 
interchange format stores the first-order hypertext 
link information embodied in the sample Intermedia 
environment in Figure 1. 

After creation of the documents, anchors, and links 
in Intermedia, the link-related information stored in 
the Intermedia database is converted into the inter- 
change format by use of the Export utility, which is 
described in Section 5. 



-218- 



The ASCII data values resulting from this conver- 
sion are shown in the following tables, as they 
would appear when viewed in a text editor (minus 
their field and record delimiter characters). These 
values fully describe the anchor, link, and document- 
properties information contained in the Intermedia 
database for the documents depicted in Figure 1. 

It is arbitrarily assumed that the ID numbers for 
both the current site and converted database arel. 
Using the rule for generating the value of the 
SitelD field noted under "Implementation," the fol- 
lowing long word is stored: 

00000000 00000001 00000000 00000001 
site number database number 

This is displayed as the number 65537. Note that 
this value is the same for every data record in the 
example. 

document info file 



11111111 
system 



11111111 
owner 



11111111 
group 



00001111 
world 



Using the rule noted under "Implementation," system 
administrator, owner, and "group" users can perform 
all operations on these documents; "world" users can 
only read them and make links in them. 

The groupName of the group referred to in the ac- 
cessRights is "iris". The creator and modifier fields 
contain the user ID of the author of this example: 
"var". 

The creationTime, expressed in Unix GMT format as 
"604771573," is Wednesday, March 1, 1989, 
4:06:13 PM. 

The docName values of the two documents are those 
shown in the documents' windows in Figure 1. The 
relative path name of the document files is that 
shown in the folder window in Figure 1. 









anchor file 






Field 


Value 


Value 












r lelCl 


Vain o 
V alUc 


V dlUc 


sit eld 


65537 


65537 














sitelD 


65537 


65537 


docID 


1 


2 














anchorlD 


1 


2 


docType 


300 


301 














anchorDocID 


1 


2 


accessRights 


4294967055 


4294967055 














creationTime 


604771726 


604771729 


groupName 


iris 


iris 














modTime 


604771726 


604771729 


creationTime 


604771573 


604771642 














creator 


var 


var 


modTime 


604771573 


604771642 














modifier 


var 


var 


creator 


var 


var 














anchorName 


Source 


Destination An 


modifier 


var 


var 




Anchor 


chor 


docName 


wordDoc 


drawDoc 


X-loc 


40 


23 


path 


demo 


demo 


Y-loc 


45 


28 


The documents in the example 


were the first created 


Z-loc 


0 


0 


in the Intermedia database, so 


their docID numbers 








are "1" and "2". 






appData 


1 


1203 



The docType uses Intermedia type codes: "300" for 
InterWord, "301" for InterDraw. 

The accessRights are stored in the bit pattern of the 
value's long word. The value for the documents in 
this is written in ASCII as "4294967055," which is 
equivalent to the bits: 



The anchors in the example were the first created in 
the Intermedia database, so their anchorlD numbers 
are "\" and "2" . Their anchorDocID values identify 
the documents they were created in: "1" (the 
InterWord document) and "2" (the InterDraw docu- 
ment), respectively. 



-219- 



The anchorNames of the anchors are "Source 
Anchor" and "Destination Anchor". These names are 
informational; they do not affect the directionahty 
of the hnk. 

The X, Y, and Z coordinates for each anchor, and 
the values in the appData field, are interpreted by 
the applications associated with the documents 
identified in the anchorDoclD field (InterWord and 
InterDraw), in ways dependent upon the document 
contents. For instance, the data value for anchor 1 
specifies the "anchor type," while the values for 
anchor 2 specify: the two objects the anchor is con- 
nected to, the "view index" of the anchor, and the 
"mark type" (these terms are included for illustra- 
tion; their definition is outside the scope of this pa- 
per). Other link-related data values that do not fit 
elsewhere in the architecture of the interchange 
format can be recorded here in similar fashion. 



link file 
Field 

sitelD 
linkID 



Value 
65537 
1 



The linkName of the link is "Demo Link". This 
value is not presently used in Intermedia, but is 
stored for consistency, in the event it is needed for a 
future version of Intermedia, or for another partici- 
pating system. 

There are a number of other fields in the inter- 
change format that are used this way, providing 
flexibility beyond the bare needs of Intermedia it- 
self. SitelD, and the creationTime, modTime, cre- 
ator, and modifier fields in the anchor and link 
files are examples. 

attribute definition and attribute files 

Although attributes were not included in this 
Intermedia example, their use in this context can be 
illustrated hypothetically. 

For instance, in order to support optional unidirec- 
tional linking, an attribute with the attName of 
"anchorType" could be entered in the attribute defi- 
nition file. Codes for "source" and "destination" 
could then be entered as values for attValue in the 
attribute file, and attached to particular anchors by 
making the requisite entries for objectType and objec- 
tlD. 



linkType 

srcAnchorlD 

destAnchorlD 

creationTime 

modTime 

creator 

modifier 

linkName 



2 
1 
2 

604771731 
604771731 
var 
var 

Demo Link 



The link between the anchors in the two documents 
in the example was the first created in the 
Intermedia database, so its linkID number is "1". 



The linkType uses Intermedia type codes: 
notes a "reference" link. 



'2" de- 



The "source" anchor of the link is the one identified 
in the anchor file by the anchorlD of "1"; conse- 
quently "I" is stored here for srcAnchorlD. The 
"destination" anchor of the link is treated in paral- 
lel fashion. Keep in mind that linking in Intermedia 
is bidirectional; the distinction between source and 
destination is maintained for participating systems 
that distinguish between the two. 



Another significant use of user-defined attributes is 
for filtering of hypertext information based on key- 
words, which are text strings attached by the user 
to hypertext objects. Keywords serve as flags for as- 
sociating objects with each other. Typical keywords 
might be "Modernism," "Mitosis," "Moon," or 
"Manichean." Keywords can be implemented by 
defining an attribute named "Keyword" and allow- 
ing users to enter their keywords as values for the 
attribute. 

document files 

The operating system files that store the contents of 
the Intermedia documents shown in Figure 1 are lo- 
cated in the directory identified in the path field 
of the interchange format's document information 
file. The names of the document files are stored in 
the docName field of the same interchange format 
file. 

As noted in Section 2, the application-specific con- 
tents and format of the document files are not con- 
sidered part of the interchange format. In order to 
support such exchange of document information. 
Intermedia provides various methods for importing 
and exporting document content data. These methods 
include the use of standard file formats, such as RTF 
(for InterWord documents), PICT (for InterDraw doc- 
uments), and TIFF or MacPaint (for InterPix bitmap 
images). 



-220- 



4.3. Other Intermedia Usage of the Interchange Format 

An early version of the interchange format has al- 
ready been used in the suite of "Webware" products 
making up part of the public release version of 
Intermedia. The procedure for installing the webs 
for "Exploring the Moon" and the Intermedia 
Tutorials into the Intermedia link server database 
involves running a script that calls the Import util- 
ity, which transfers web data in the interchange 
format from a floppy disk to the Intermedia server 
hard disk. The Import utility is described in Section 
5 of this paper. 

This early prototype of the interchange format does 
not support attributes or SitelDs, and the storage for 
anchors is tailored to their treatment within 
Intermedia. 

5. UTILITIES FOR THE INTERCHANGE FORMAT 

A number of utilities have been created for use with 
the interchange format. Some of the utilities process 
the data of the interchange format to validate the 
data, others are used in conjunction with the the 
Intermedia Link Protocol Server ("the link server") 
to import and export data into the Intermedia 
database. 

5.1. Verify 

The Verify utility checks the consistency of the in- 
terchange format files. It ensures that all documents 
exist for all anchors, and that all anchors exist for 
all links. If keywords are implemented, the utility 
ensures that all documents, anchors, and links exist 
for all keywords. A series of hash tables is used 
during the checking process. If any ID is not in the 
hash table, the object being processed is removed 
and placed in an error file, and the user is informed. 

5.2. Export and Import 

The Export and Import utilities are used to extract 
and store, respectively, the data from Intermedia's 
database using the link server. 

Earlier prototypes of these two utilities were help- 
ful in the conversion of our Intermedia databases 
when we exchanged Ingres for the Intermedia link 
server and its new database system based on C-Tree 
[Fair88]. The utilities have also helped us convert 
databases from one data dictionary format to an- 
other, by running Export with an old-format server, 
and Import with a new-format server. 

The Import utility reads the files of the interchange 
format and calls the import functions of the link 
server to add the data to the database. One param- 
eter to the utility specifies whether to create new 
IDs for each object being added to the database or to 



reuse the existing object IDs. This feature allows us 
to either append data to the end of the database 
(with new IDs), or replace the data in the database 
with new data (having the IDs of the existing ob- 
jects). Using the "replace" feature we are able to 
change the location of the document tree without 
having to change the IDs for the documents. The 
other parameters to the utility specify the Unix file 
system locations for the location to read the inter- 
change format from, the name of the database to 
add the data to, and the new location for the docu- 
ment tree. 

The Export utility caV.'j. the export functions of the 
link server to dump all data from the database into 
the interchange format. The Verify utility can be 
run in conjunction with Export, to ensure data in- 
tegrity. The parameters of Export are the same as 
those of Import that deal with Unix file specifica- 
tions, except that Export writes where Import reads, 
and vice versa. 

5.3. Future Developments for Utilities 

The utilities described here have been integrated 
into an application that will potentially be in a 
publicly available version of Intermedia. This ap- 
plication, called Transfer, enables users to select 
document, anchor, and link information to be ex- 
ported by selecting folders and their contents (i.e., 
documents and webs). In order to maintain the in- 
tegrity of all the webs in the selection, documents 
that lie outside the selection in the folder hierar- 
chy, but have links or anchors in a selected web, are 
also exported. When exporting, the user can select 
the type of media to export the data to. Hard disk, 
floppy diskette, and tape are currently supported. 
Users can also import previously exported data, 
from the same media types. 

At present, the Transfer application generates data 
in a form of the interchange format described here. 
It is intended that the application be able to gener- 
ate any of a number of other formats as their defini- 
tion and use becomes available. 

There are also plans to create other utilities to en- 
able the conversion of first-order interchange for- 
mats into second-order interchange formats, or from 
prototype first-order interchange formats into pro- 
duction first-order interchange formats, as their 
needs arise. 

6. OTHER INTERCHANGE FORMATS 

At the time I developed the interchange format de- 
scribed here, I knew of no other hypertext inter- 
change formats under development. Many design 
elements in this interchange format apply specifi- 
cally to the requirements of the Intermedia system. 



-221- 



However, the major conceptual elements are common 
to most other hypertext interchange formats. 

In this described interchange format, the structure of 
the data file is static, while the the data that fills 
that structure changes dynamically. A format like 
this is very simple to implement. Hov/ever, when 
interchanging with other disparate systems this in- 
terchange format becomes very difficult to use. 
Converting its structure to a tagged format, like 
SGML, would make it more portable. 

It should be possible to ceo vert this format to the 
X3V1.8M interchange format [Gold89] with rela- 
tively few or no extensions to the HyTime DTD. 
However, there are several drawbacks in doing this. 
First, none of the documents in Intermedia are stored 
in SGML format, so references to components of the 
documents may be difficult. Second, the link-and-an- 
chor database is separate from the document 
database, in order to support linking to non-writable 
media (like CD-ROM disks) and to support multiple 
Vt^-eb mappings over the same document sets. 

The task of converting this data structure to support 
any of the interchange formats [Born89] that conform 
_ to the Dexter model [Hala89] would be possible as 
well. This would require adding tags and attributes 
the the existing data elements with some minor re- 
organizations. This is planned as a future project. 

6. SUMMARY 

In this paper a format is documented, that shows the 
structure of the data files and the minimum infor- 
mation necessary to transfer hypertext information 
from one first-order hypertext system to another. 
These data files, when combined with a methodol- 
ogy for converting and transferring the contents of 
application document files, embody an interchange 
format enabling the full exchange of information be- 
tween existing hypertext systems. This was demon- 
strated by the use of the interchange format to 
transfer data into and out of Intermedia. 

It is hoped that this format could be a base of ideas 
in developing an interchange standard for first-order 
hypertext systems thus enabling the sharing of hy- 
pertext information more freely. 

The need remains to establish and publish conven- 
tions for assigning values in the SitelD, docType, 
linkType, attDeffype, attValType, and objectType 
fields, to insure compatibility between the systems 
on both ends of a data exchange. 



8. ACKNOWLEDGEMENTS 

I wish to thank everyone at IRIS for their help dur- 
ing the writing of this paper, especially Jim Coombs 
and Norm Meyrowitz for being the best sounding 
boards for my ideas, and Mark Saw telle for assis- 
tance in preparing the text. 

REFERENCES 

[Born89j J. Bornstein, "Hypertext Interchange Format- 
Discussion and Format Specification—DRAFT 1,3.3", 
September 1989. Available from author. 

[Camp88] B. Campbell, J. Goodman, "HAM: A General Purpose 
Hypertext Abstract Machine," Communications of the 
/ACM,31(7):856-861, 1988. 

[Conk87j J. Conklin, "Hypertext: An Introduction and Survey," 
IEEE Computer, 20(9):17-41, 1987. 

[Enge68j D. Englebart, W. English, "A Research Center for 
Augmenting Human intellect," Proceedings of FJCC, 
33(1):395-410, AFiPS Press, f^^ontvale, NY, 1968. 

[Fair88] FairCom, c-tree™ File Handler Programmer's 
Reference Guide, FairCom, Columbia, MO, May, 1988. 

[Gold89] C. Goldfarb, A. Talbot, Journal of Development, Part 
Two: Standard Music Description Language (SMDL) 
Hypermedia/Time-based Document Subset (HyTime). 
ANS! X3V1.8M, The Computer Music Association, P.O. 
Box 1634, San Francisco, CA 94101-1634, October 
31, 1989. 

[Ha!a89] F. Halasz, M. Schwartz, "The Dexter Hypertext 
Reference Model", to be presented at the N!ST 
Hypertext Standardization Workshop on January 16, 
1989. 

[Meyr86] N. Meyrowitz, "Intermedia: The Architecture and 
Construction of an Object-Oriented Hypermedia 
System and Applications Framework," OOPSLA '86 
Proceedings, 21(11):186-213, ACM SIGPLAN 
Notices, November, 1986. 

[Nels81j T. Nelson, Literary l\/lachines: The Report on, and of, 
Project Xanadu, Concerning Word Processing, 
Electronic Publishing, Hypertext, Thinkertoys, 
Tomorrow's Intellectual Revolution, and Certain other 
Topics Including Knowledge, Education, and Freedom, 
Sv;arthmore, PA, 1981. Available from author. 

[Yank88a] Yankelovich, N., Haan, B., Meyrov^'itz, N. and Drucker, 
S., Intermedia: The Concept and Construction of a 
Seamless Information Environment, iEEE Computer, 
21(1):81-96, 1988. 



Strawman Reference Model for Hypermedia Systems 

Craig W. Thompson 



Information Technologies Laboratory 
Texas Instruments Incorporated 
P.O Box 655474, MS 238 
Dallas, Texas 75265 
Email: thompson@csc.ti.com Telephone: (214) 995-0347 

Abstract 

This paper provides a strawman reference model that can be used for comparing and rea- 
soning about hypertext/hypermedia systems. It begins with a glossary of hypermedia terms. 
Agreeing on these provides a common vocabulary for developing the reference model. The ref- 
erence model itself is presented in terms of basic features all hypermedia systems have, advanced 
features some hypermedia systems have, and open features that hypermedia systems share with 
other computer systems. These features represent independent dimensions which can be used 
to classify or compare existing hypermedia systems and to contrast thern with near-miss related 
systems. Based on the features, the architecture of an ideal hypermedia system is described 
that covers existing hypermedia systems. The architecture is modular. A consequence is that 
discussion of standards or a more detailed reference model can focus on one module at a time, 
avoiding movement toward a portmanteau standard. The final section of the paper evaluates 
some areas where consensus and eventual standardization of hypermedia systems is possible 
and would be valuable. An appendix references some standards related to hypermedia sys- 
tems. Another appendix is an initial document log listing references important to hypermedia 
standardization. 



-223- 



] INTRODUCTION 



1 Introduction 

The premise of the Hypertext Standardization Workshop is that "hypertext and hypermedia tech- 
nologies have reached the point where it makes sense to consider their potential for formal stan- 
dardization" [Workshop Call for Papers]. 

This paper provides a strawman reference model that can be used for comparing and reasoning 
about hypertext/hypermedia systems and suggests some areas where enough consensus could occur 
to make eventual standardization possible. 

Section 2 provides an (incomplete) glossary of hypermedia terms. A standard glossary would 
provide a common vocabulary for implementors and users of hypermedia systems. This level of 
standard promotes communication among people. 

Section 3 presents a strawman hypermedia reference model. Standardizing on a reference model 
should make it possible for people to compare different hypermedia systems and other closely related 
systems. The section demonstrates this by using the dimensions of a hypermedia system described 
in the reference model to compare several hypermedia systems. The section concludes with an 
ide?J, modular architecture for a hypermedia system. 

Operational standards should make it possible for computer systems to share data or interface to 
each other. Section 4 evaluates potential areas, indexed to the reference model, where operational 
standards for hypermedia systems may be possible and would be valuable. 

Appendix A references some existmg standards related to hypermedia systems. Appendix B is 
a place holder for the document log that a hypermedia systems study group would maintciin. 

In fact, overall, this paper can be viewed as the skeleton for a Final Report of a study group 
yet to be formed recommending whether and what hypermedia standardization is useful. Such a 
report might lead to the formation of an official standards body charged with formulating detailed 
hypermedia standards. 

2 Glossary 

The purpose of the glossary is to register terms and how they are used in different hypertext 
systems. The value of a glossary in standardization is to provide a common vocabulary so we all 



-224- 



2 GLOSSARY 



understand common terms the same way and can distinguish their various overloaded meanings. 
In addition, glossary terms are important in the development of a reference model (section 3) and 
provide a simple approximate way to scope a domain. Here we only list some of the more prominent 
terms that need to be defined. 

hypertext 
hypermedia 
browser 
editor 

hypermedia abstract machine 

unique id 

node 

cut-and-paste 
link 

warm link 
hot link 
field 
button 
anchor 

link service 

link protocol 

content 

annotation 

version 

conf iguration 

web 

network 

guideline 

stack 



-225- 



3 REFERENCE MODEL 



card 

background card 

field 

locktext 

script 

scroll 

bookmark 

history 

map 

open architecure 

Here we only comment that some terms like link are heavily overloaded. Other terms like node, 
card, frame are system-specific names for the approximately the same concept. 

3 Reference Model 

A hypermedia reference model is an English description of characteristics that "cover" existing (and 
future) hypermedia systems and provide people with a way to compare them. 

Subsections 3.1, 3.2, and 3.3 sketch basic, advanced, and open features of a prototypical hy- 
permedia system. Each feature represents an independent dimension in which hypermedia systems 
vary. Subsection 3.4 compares how some existing hypermedia systems fit this model and how some 
near-miss systems compare. Subsections 3.5 and 3.6 describe an "ideal" architecture for a hyper- 
media system based on the premise that orthogonality implies modularity. If this premise is correct, 
we should expect to concentrate standardization efforts on modules, not on whole systems. 

3.1 Basic Features 

All hypermedia systems have the following basic characteristics or dimensions through which they 
vary and can be compared. 



-226- 



3 REFERENCE MODEL 



The representation dimension provides the primitive media types or content part, and the cona- 
positional data model or structural part, that together are used to represent information in a 
hypermedia system. It is convenient to distinguish these two sorts of representations as separate 
dimensions. 

Media Types. A hypertext system must be able to represent text (as well as structure). A 
hypermedia system adds other media types (bitmaps, graphics, sound, video). Specialized media 
editors are needed to permit WYSIWYG editing of media types. Compression of media types 
may be supported; automatic conversion between some media types is supported (e.g. graphic- 
to-bitmap). (Various) standards already exist for representing many of these media types (see 
Appendix A). 

Data Model. A data mocie/ provides the structuring primitives^ of the hypermedia system. To- 
gether, the data model and media data types are used to represent ox encode the application-specific 
information content in a hypermedia information system. Specialized hypermedia interpreters, usu- 
ally with built-in operations, operate on the basic data structures of the data model. 

Data modeling is the most interesting and diverse dimension of hypermedia systems. The com- 
mon invariant that all hypermedia systems share is the notion of navigating through an information 
space by following links. Beyond that, systems vary widely, most implementing some sort of se- 
mantic net with more or less structure. Many hypermedia glossary terms describe system-specific 
data model concepts (e.g., stack, card, history). Nodes may be inherently unstructured; they may 
have built-in or user programmable types; or they may have attributes, fields, or buttons. Links 
also vary. Most are binary; they may be typed and have attributes; they may anchor at nodes or 
within nodes in a media- or type-specific or application-specific way; or they may be built from 
lower level primitives {anchors and go to's as in HyperCard). 

While data models differ across different hypermedia systems, they are nearly always built-in to 
today's systems. Later, in section 4 we wiU consider when and whether mappings between different 
data models are possible. 

User Interface. The user interface provides the capability of viewing and editing (WYSI- 
WYG) presentations of information represented by the data model and media types. 

Hhe hyper in hypermedia 



-227- 



3 REFERENCE MODEL 



Some hypermedia systems like KfvIS and HyperCard use the metaphor of a "notecard" and only 
provide fixed (screen-sized) cards with only one card visible at a time. Others like NoteCards use an 
overlapping or tiled window system metaphor of flexible-sized cards with the content and structure 
of a card still tied one-to-one to the display window. Guide provides scrolling and progressive 
disclosure, a step towards providing the user with control of which objects he can see on a screen. 
More generally, a many-many view mapping like that in CMU Andrew covers all of the above cases. 

Persistence. Hypermedia systems all provide some notion of transferring application-specific 
content and structure to and from some persistent storage repository. They vary on the unit of 
transfer (e.g. Guide document, HyperCard card, Notecards application) and the file or database 
format they use to encode the data represented by the data model. 

3.2 Advanced Features. 

Not all hypermedia systems have the following advanced characteristics. While not mandatory 
(essential, intrinsic, defining), they complement the basic features and are needed for non-trivial 
hypermedia systems. 

Multi-usei". Computer-supported cooperative work requires many users to access shared data. 
Some hypermedia systems support this. Sharing by multiple users adds the need for some concur- 
rency control scheme like locking or time-stamping so users can coordinate access to shared data. 
Data and/or structure may be read-only or modifiable according the access rights of users. Users 
can be granted different access rights at different times or for different purposes. 

Distributed. Even for a single user, hypermedia data may be stored in a central repository or 
be distributed. For instance, content may be on a WORM device and structure may be stored in 
a relational database. 

Uniform Representation^ Many hypermedia systems make a distinction betw^een node and 
contents. This forces the user to "chunk" the information he wants to represent into some fixed 
grain-size. This can lead to users spending time manually restructuring information. Advanced 
systems provide a more recursive formulation of the data model allowing content to contain nodes 

'This feature is not independent of the data modeling feature presented earlier but is included here as a major 
dimension for comparing advanced hypermedia systems. 



-228- 



3 REFERENCE MODEL 



(further structured information). This extra information plus a richer mapping of the more uniform 
data model to the user interface can give the user many views of the same information. Systems 
like Guide begin to take advantage of this by allowing the user to control which objects are visible 
using progressive disclosure. Intermedia webs allow two or more views to "share" common nodes. 
Systems like Lotus Agenda allow the user to reorganize the information based on a simple form of 
computed view. The semantics of sharing common objects from different perspectives can lead to 
dangling pointers and view update problems. 

A different aspect of uniform representation involves the ability to deal with foreign nodes. 
These are nodes whose contents are opaque to the hypermedia system. For at least two reasons, 
uniform representations must generalize to account for these foreign representations. First, not aU 
workstations can display all information, so video or even graphic information will remain opaque 
on these workstations. Second, hypereditors like KMS or Neptune can bind to non-hypereditors, 
like word processors, that do not understand link protocols (are not themselves uniform; do not 
represent their internal information in a way the hypermedia system can interpret). In this case, 
links typically anchor to whole nodes, which act to "wrap" the foreign editor, or else link anchors 
consist of two parts, a node id and a specifier, often written in a script language that can be 
interpreted by a foreign tool, telling how to offset into the foreign representation. Sun provides an 
application-independent Link Service protocol for standardizing cross-application linking as does 
HP New Wave. 

One last variation in representation is whether hypermedia systems permit users to define the 
scope of objects like figure, section, document, library, video clip, or whether these types are built- 
in. 

Computational Completeness. The computational completeness dimension describes how 
procedural information can be associated with the hypermedia data model to model behavioral 
aspects of the information. 

Procedures can be coupled with data in many ways. Most characteristically, an anchor contains 
a script (procedure in a language specialized to the data model as in HyperCard) that is triggered if 
the anchor is activated. Alternatives are demons and rules as in Object Lens, procedures in general 
purpose languages as in NoteCards, assertions, and so on. Since procedural attachments are added 



-229- 



3 REFERENCE MODEL 



dynamically, there must be an interpreter or dynamic compiler. 

This dimension is the hardest to transport across systems, as we discuss in section 4. 

Query. Hypermedia information spaces are often large. Navigation is used for browsing; 
bookmarks for going to known places. Search is used for locating items of interest by their charac- 
teristics. Some dimensions of search include limiting the scope or order of a search; string search 
versus indexing text; boolean search predicates and their possible use of indices; user-defined search 
predicates; incremental search; and how the end user can easily specify complex searches. 

Another dimension involves what to do when search is successful. Alternatives are that the 
search results in a computed path through the information space or in a new view of the information 
space. Much work from the database and information retrieval areas is useful here. Query is a very 
rich dim.ension. 

General-purpose procedural attachments generahze query capabilities and many hypermedia 
systems contain weak or no specialized query facihties. This leaves the burden of specifying complex 
queries to the user via programming. 

Versions, Configurations. Especially for design applications (e.g., documents, software), 
where the life cycle of a design needs to be represented, a Change Tl/anajfemenf data model consisting 
of versions, configuratioiis a,nd transformations Is useful for recording change, how a complex object 
is composed of its parts, and how change propagates. 

Portmanteau Features. Subsection 3.4.2 describes near-miss systems closely related to hy- 
permedia systems. We can mine these systems for other characteristics that hypermedia systems 
could have.'' This could overload hypermedia systems with more than their ordinary meaning but 
the exercise is needed to determine how these systems differ from hypermedia systems. 

3.3 Open Features 

Open features are generic and belong to many or all computer systems. They may apply in special 

''For example, few if any hypermedia systems provide parsers to automatically recognize structure in unstructured 
information. This is clearly important since a whole hypermedia business could be built around structuring the mass 
of unstructured information. Most parser technology is aimed ?i recognizing already designed languages. The Oxford 
English Dictionary project at University of Waterloo is one place to look for good ideas on the interplay between 
parsing, querying, and computed data models induced by a grammar. 



-230- 



3 REFERENCE MODEL 



ways to hypermedia systems. 

Hmnan Factors. This dimension measures how likeable, usable, and effective a system is for 
the tasks it is designed or needed for. 

Open versus Closed Architectures. Hypermedia systems vary along the dimension of hov/ 
closed or open they are; that is, how extensible they are. Some aspects of openness are: 

• none browsers 

• editing only - simple authoring systems like Guide 

t user can add node and link types; or can specialize classes the system defines. 

• user can provide procedural attachments 

• system has an application program, interface 

• system is modular and modules can be replaced 

Monolithic versus Modular Architecture Today's hypermedia systems are monolithic. An 
alternative is a modular, toolkit architecture in which modules can be added or replaced as the need 
arises. This would mean that design applications could make use of the change management module 
but other applications would not have to pay this cost. If some specialized change management 
is needed, only that module is replaced. The modules themselves may be open--e.g., the query 
optimizer could be programmable; the version scheme's notion of deltas could be too; pragmas 
might control how objects are clustering on disk; new kinds of presentations could be added to the 
user interface. A key issue related to modularity involves determining the protocols an existing 
foreign editor must implement to become a friendly hypereditor. It is more likely that "the world's 
best editors" can be modified to be hypermedia-conformant than that hypermedia editors will come 
to rival these editors. 

Portability and Industrial Strength. The portability dimension describes how a system is 
bound to its environm.ent and how easily it can be moved to other environments. It will be more 
portable if 1) it is implemented on de facto standard, industrial strength platorms (Unix, DCS. 
X-Windows, C + + , SQL, etc), 2) it contains alternative, equivalent implementations for different 



-231- 



3 REFERENCE MODEL 

environments (Open Look versus Presentation Manager), and 3) it can exchange data with many 
existing, popular data exchange formats. 

A hypermedia system is industrial strength if 1) it is debugged and maintained, 2) it scales 
up for large hypermedia bases, 3) performance is acceptable, 4) it has (online) documentation and 
tutorials, 5) it is portable, and/or 6) it is being used in practice. 

Cost, Availability, Service. The world's best designed hypermedia system is worth less if it 
is too costly, unavailable, breaks, and so on. This dimension is a non-technical road block to many 
systems. 

Packaging. This characteristic represents the particular binding of all previous characteristics 
that defines any given system. It is measured by some sort of success metric. 

3.4 Comparison of Existing Systems 

If the reference model just defined is successful, we should be able to compare existing and related 
systems using the dimensions it defines. 

3.4.1 Comparison with Other Hypermedia Systems 
Figure 1 makes this comparison for existing hypermedia systems. 





HyperCard 


Notecards 


Guide/IDEX 


Intermedia 


KMS 


media types 


bitmaps text 
sound 


text bitmaps 
other 


text 

import bitmaps 


all 


text 
graphics 


d&tA model 


stack 
f/bkgnd card 
field button 
go to 


card 
fllebos 
link 
other 


guideline 
buUon note 
replacement 
inquiry 


web 
node 
link 


network 

frame 
6eld link 


user interface 


card = jcreen 
11 
jcroll text 


card = wlndow 
1 I 

scroll node 


IN 
scroll 


card = window 

1:1 

scroll node 


card = screen 
11 

no scrolling 


persistence 
unit of tranifcr 


card 


application' 


guideline/node 


node 


frame 


muUi- user 


no 


ne ' 


no/yes 


yes 


ye* 


distributed 


no 


no 


no / yef 


yes 


yes 


uniform 
representation 


no 


no 


limited 


no 


no 


programmable 


script XCMD 


lisp 


no/guidance 


no 


action 


query 


no 


no 


no 


no 


no 


change management 


no 


no 


no 


no 


no 


open data model 


mirror 


any 


no 


no 


mirror 


monolithic vs 
modular 


monolit hie 


monolithic 


monolithic 


monolit hie 


monolit hie 



Table 1: Comparison of Hypermedia Systems by Basic/ Advanced Feature 



-232- 



3 REFERENCE MODEL 



3.4.2 Relationsliip of Hypermedia Systems to Near-Miss Systems 

A hypermedia reference model must also allow comparison with similar systems that are not usually 
classified as hypermedia systems. The big question is, if we factor these systems into their 
characteristic dimensions, then how much overlap would there be between systems.^ 

Prograrmning language data structures mclndlng object-oriented programming^ and A I knowledge 
representations including frame-based systems^ carry data modeling much further than hypermedia 
systems do today. They provide better uniform representations but have no particular support 
for foreign objects. In particular, object-oriented programming languages like C + + , CLOS, and 
Smalltalk have common characteristics including object identity, encapsulation, types or classes, 
and (multiple) inheritance; and they provide procedural attachment. These systems make a strong 
type-instance distinction and some only allow creation of new data types at compile time. 

Persistent programming languages make the data model of the programming language incremen- 
tally persistent, managing secondary storage, concurrency, and recovery. Object-oriented databases 
add sets, queries, and indexing; and also change management and schema evolution to persistent 
languages, but take no particular stand on user interfaces. As such, they generalize relational 
database systems, though implementations of the latter are far more mature. Even more special- 
ized are implementations of information retrieval systems which store large text bases persistently, 
support indexing, but typically provide no editing, data modeling, and only specialized query lan- 
guages. Geographic information systems store graphical information in often-specialized databases. 

User interface management systems allow simple user interfaces to be built quickly. User inter- 
face toolkits like Stanford Interviews and CMU Andrew provide general purpose interface building 
kits but require programming to put the pieces together. They do not commit to any particular data 
model. In general, object libraries are a way to package up collections of related objects for reuse in 
building large systems. Structured graphics editors can make use of such systems to build generic 
shapes. Programming language inspectors and class browsers can be viewed as specialized hyper- 
media systems for viewing rich representations. DIKED editors, e-mail previewers, CAD schematic 
editors, CASE interfaces, and other semantically specialized graphics editors can browse and edit 

*A related implementation question is, are we building almost the same systems over and over without factormg 
out the common modules' 



-233- 



3 REFERENCE MODEL 



many views of domain-specific structured data types. Personal Information 5i/5i!e77i5 like Symantec 
GrandView and Lotus Agenda provide many views, including hierarchical views, of simple records 
via cross indexing. 

The kind of objects represented by these systems are usually but not necessarily fine-grained. 
Computer-aided publishing (CAP) systems add primitive objects like text rectangles that may be 
large and may contain embedded objects. Text and document markup languages represent the 
content of very rich hypertext-like systems often specialized to document preparation but also used 
as the external representations of WYSIWYG document preparation systems like Framemaker. 
Syntax-directed structure editors parse structured text and permit editing, pretty printing, and 
controlled viewing of programs. 

Finally, where Office Document Architecture only distinguishes a structural and a page layout 
architecture for text, graphics, and other static media, technologies like Digital Video Interactive 
specify how to temporally sequence video and sound and introduce compression. 

All of these systems are almost hypermedia systems. Some introduce new features including 
richer data modehng and compression; others seem more like elements of a hypermedia toolkit since 
they overlap hypermedia systems concentrating only on one basic or advanced feature or another. 

3.5 Architecture of an Ideal Hy permedia System 

Figure 1 represents an ideal hypermedia system that covers all of the basic and advanced features 
described earlier in this section. The key point of the architecture is that it is modular and 
open. This modularity is based on the observations that the functions the modules perform are 
independent of each other, that is orthogonality implies modularity. The only required modules for 
a basic hypermedia system are the User Interface Toolkit, Domain-specific Data Modeling, Type 
and Object Manager, and Persistent Storage modules. 
Module independence is justified as follows: 

• Media types provide primitive representations for text, bitmaps, audio, video, graphics. 

• The data model represents structure (nodes, relationships, and content) uniformly. It defines 
what the hypermedia system can represent. Speciahzations can define hypermedia objects 
like card or field or they can define domain-specific objects like transistor or module. 



-234- 



3 REFERENCE MODEL 



Change Management 

Control versions, configu- 
rations, and translormatlons 
Schema evolution 



Object Query 

Associative, optinriizable 
queries over collections 
of objects 



Extended Transactions 

AppDcatlon-spedflc concur- 
rency control (non 2-phase) 
^49ste^d transactlorts 
■Cooperative wort< 



tJser Interface 
Too Ik H 

-Object-oriented browsing 
•Progressive disclosure 



.^.<';-Siv'/.%'-:-;-:-i':-^>^-ii^ 




Domain Specific Data Modeling 


■Hyperrriedia, CAD, CASE, etc. 


Type Manager 


Object Manager 


-Type definltltons 


-Maintain consistent 


-Media types 


runtime environment 







Programming 
Language 



Persistent Object Store 

-Object storage with 

object identity 
-Use of Inter-object refer- 

ervces for placement 



Object Communlcallons 

-Reliable delivery of objects 
-Remote Procedure Calls 



Object Translation 

-internal <-> external 
object transaltion 



Transactional Store 

Atomic, recoverable storage 
of untyped "bit-buckets" 
Rudimentary concurrency control 



^M^-^ Message passing BUS 



Figure 1: Proposed Ideal Hypermedia System Architecture. 

• Structure and content can be displayed in many ways (or not at all) so the presentation 
layer is independent. This can be implemented with a data model-independent user interface 
toolkit. 

• Whether and how this information is mapped to permanent storage is again independent of 
what is represented, so the storage system is orthogonal. Implement this with an persistent 
programming language.^ 

• Queries and indexing are related only to whether there are sets, collections, or other navigation 
paths to iterate through and whether there is cached information (indexes) that can be used to 
limit the search. Implement this with the open query module of an object-oriented database. 

• Systems may or may not version their structure and content. How they do this, if they do, can 



^View-independence and Storage-independence from representation are similar to the famous 3-tier model of 
databases. 



-235- 



REFERENCE MODEL 



be studied independently of what they represent, how it is viewed, or whether it is persistent. 
Implement this with a separate Change Management module. 

• From a single users point of view, whether the system is multi-user or not is largely trans- 
parent; the same goes for whether the system is distributed. 

• Implement the above functions modularly with weU-defined interfaces specified between mod- 
ules. 

3.6 Advantages of this Architecture 

A modular, toolkit architecture like the one described in the previous section has these ad- 
vantages: 

- The architecture could be used to build existing hypermedia systems. In that sense, it 
covers and explains these systems. 

- Related systems are implementing several of the modules needed in an ideal hypermedia 
system. Work on class Hbraries, persistent languages and OODBs, and user interface 
toolkits is proceeding in parallel with work on hypermedia systems. 

- Since the architecture is modular, modules can be improved individually which would 
incrementally improve the system. They can be improved by different research groups or 
vendors. People need not build whole hypermedia systems to experiment with particular 
parts. 

- It will be easier to build the near-miss systems using a modular hypermedia toolkit and 
the extra capabilities they add to the toolkit will likely benefit existing applications. 

- Customized system that only use the modules they need can be constructed. 

- If the modules are orthogonal, then consensus that leads to standardization should con- 
centrate on individual abstractions, not portmanteau standards covering many essen- 
tially independent parts. 

The architecture proposed here is similar to the proposed architecture for Application Inte- 
gration Frameworks being developed by several industrial consortia. These include: USAF 



-236- 



REFERENCE MODEL 



WRDC Engineering Infoimation Systems (EIS), Object Management Group (OMGj, CAD 
Frameworks Initiative (CFI), and CASE Integrated Systems (CIS). As shown in Figure 2, all 
these efforts provide an object-oriented software backplane architecture into which software 
services are "plugged." This allows new applications that use the common services of the 
framework to be built more quickly and to have a "uniform semantics." Applications are 
simpler to implement since common services are factored out and provided by the framework. 
To date, framework services include common link protocols like Sun's Link Protocol, help 
and tutorial services, debugging services, and change management services, all implemented 
on top of file systems. 



Generic 
Services 




Available from 
Framework vendors 



Today's Application 

-Core o( application 
+ 

-User Interface 
-Help 
-Tutorials 
-Data modeling 
-Storage 




Application 



Modular OODB / Hypermedia S*rvlc«s 



S 

Q. 
1 



5 

9! 



r 

o 



8 
1 



E 
o 
•i 

11 



o 



c 



S 



t 

s 
I 



€5 



81 
S 8 

ii 



Message-Passing "BUS" ~ Software BacKplana 





atlon 


0 




2 


1 


Q 




< 


s 



Services 



Tools and 
Applications 



Figure 2: Hypermedia Modules complement Application Integration Frameworks. 



Missing ingredients from these framework architectures are the modules offered by a modular 
OODB, which would permit sharing at the object grain size instead of the file grain-size and 
querying. Also missing are user interface toolkits and data rrnodeling facilities needed by a 



-237- 



OPERATIONAL STANDARDS: WHERE IS CONSENSUS POSSIBLE? 

hypermedia system. The fram_ework view of the world as modular services fits very well with 
the proposed modular hypermedia system architecture. 

3.7 Conclusion 

The reference model presented in this section is incomplete. More work is needed to refine 
it in many places. Nevertheless, we have shown how it provides a way to compare existing 
hypermedia systems along orthogonal dimensions and have indicated that it can be extended 
to relate hypermedia systems to several kinds of near-miss systems. Based on the features 
of hypermedia systems, an ideal architecture for a hypermedia system was presented and 
advantages of this architecture were described and related to the architecture of Applica- 
tion Integration Frameworks. An argument was given for how a modular architecture can 
accelerate progress towards hypermedia standardization. 

4 Operational Standards: Where is Consensus Possible? 

Operational standards provide means for different computer systems to agree to communicate 
or interface or share. Many sorts are possible in the hypermedia area, reflecting the indepen- 
dent dimensions of the reference model presented earlier. This section identifies some areas 
where hypermedia standardization might succeed and be useful. 

4.1 Common Media Type Representations. 

Standards already exist in this area. Appendix A lists some of these. Different media have 
different properties (linea,r or 2-D in time or space, discrete or continuous, etc). Conversions 
among some media representations are algorithmic but lose information (e.g., structured 
graphics to bitmap, high resolution to low resolution). Often, higher-level structured (or 
other media) representations are represented in media representations. In some cases we 
know how to parse the media ajgorithmicaily to recognize this information; often we do not. 



-238- 



OPERATIONAL STANDARDS: WHERE IS CONSENSUS POSSIBLE? 



4.2 Common Hypermedia Abstract Machine and Interchange Format. 

The data modeling module of a hypermedia system (including the media types) can be rep- 
resented equivalently as 1) an abstract machine which includes a specification of operations 
on data (an interpreter) plus an internal representation of the data it can operate on or 2) 
an external format that encodes the application-specific content of the system for storage or 
transmission. 

The Neptune Hypermedia Abstract Machine (HAM) [7] describes a semantic-net abstract 
machine that includes not only data modehng primitives but also operations for managing 
change and querying. Representation primitives are nodes, attributes, and values. 

By itself, a semantic net data model is so weak that it permits any structural information 
to be encoded. As such, it represents very little unless an interpreter looks at the data (at 
attribute names Like type). An ASCII Unear representation of a semantic net would have the 
same semantic-less information-bearing properties. 

A semantic net representation could be standardized as could an associated linear represen- 
tation format. The linear format could use Lisp-like parentheses, SGML-like tags, or an easy 
to parse, hard to understand binary format. But this by itself says nothing about whether 
hypermedia systems can exchange hypermedia data or cooperate. 

4.3 Common Data Model. 

The heart of a hypermedia system is the information it can represent. Distinctions like text 
rectangle, frame, card, field, button, breadcrumb, and so on provide this information. Differ- 
ent hypermedia systems will be able to exchange information only to the extent that there are 
mappings between their representation primitives. It may often be reasonable to map a font 
from one system to a different font in another (but not always for all purposes). It may even 
be reasonable for som.e purposes to set up mappings from KMS frames to Intermedia nodes 
to HyperCard cards to Notecards. Similarly, Intermedia links can be mapped to HyperCard 
fields with simple scripts containing "go to"s. If N hypermedia systems represent the same 
object then a mapping to an intermediate form does not lose information and can be useful. 



-239- 



OPERATIONAL STANDARDS: WHERE IS CONSENSUS POSSIBLE"^ 



We often need to perform mappings between different system's representations: if conversion 
from one system to another is required, we try to map as much information as is useful. 
In most instances, some amount of conversion can happen algorithmicaUy. It is not too 
interesting that specific content can be moved between hypermedia systems with application- 
specific mappings. The interesting case involves whether application-independent conversion 
routine between two systems are useful or possible. 

In general, mappings can be one-way (no inverse); they can be non-unique; and they can lose 
information. All these cases happen in important hypermedia system. Because of the power 
of scripts, the inverse of mapping Intermedia links to HyperCard fields and go-to scripts is 
not unique. HyperCard foreground and background cards can be mapped to KMS frames 
but the "inheritance" is lost. Guide's variable-sized text nodes would need to be mapped 
to several KMS fixed-size frames. Structured graphics imported into Guide is converted to 
bitmaps, losing the structure. And so on. 

Even when a mapping is established, data exchange between different hypermedia systems 
will often not preserve the look antf /ee? of different hypermedia systems. Thus a Guide node 
may map to a HyperCard text field but the progressive-disclosure-in-context look and feel of 
Guide outline processing will be lost. 

With all these caveats, it is often useful to build generic conversion programs. PC and 
Macintish application commonly convert data to their own internal formats, often losing some 
information. References [13-15] describe systems that explore the problems associated with 
mapping between different document representations. The Berkeley Vortex system explores 
how to maintain an incremental, multiple representation mapping between a WYSIWYG 
editor and a markup language representation. 

While it is fruitful to try to define intermediate forms like the Dexter Hypermedia Interchange 
Format [6] that permit mapping information between today's intermediate forms (since it 
points out exactly where the mappings cause problems), it seems unlikely that the behavioral, 
script component so dominant in HyperCard can be captured without duplicating the entire 
HyperCard script interpreter in some related Hypermedia system. It may be better to consider 



-240- 



OPERATIONAL STANDARDS: WHERE IS CONSENSUS POSSIBLE? 



whether richer, more uniform representations are better than cards and slots. 

4.4 Common Object Libraries. 

The X Consortia is considering a standard C-f--f interface to X-Windows. [13] describes a 
portable Office Document Architecture toolkit consisting of C subroutines associated with 
the CMU Andrew Toolkit. Stanford Interviews is a C + + class library implementing a user 
interface toolkit. It seems likely that we could standardize on C++ hbraries in these sorts 
of area. Such libraries could implement cards, buttons, and so on but could also uniformily 
implement CAD transisters and layout structures. 

4.5 Standard OODBs. 

X3/SPARC/DBSSG has recently announced the OODB Task Group which is chartered to 
assess the potential for standardization in the OODB area. This is especially interesting since 
many hypermedia researchers look forward to using OODBs to help implement large, shared 
hypermedia systems. This effort itself may involve several standards: how to seamlessly 
interface OODBs to various languages to provide persistence and sharing, and how to map 
data between languages (hke Sun's XDR) to allow cross-language sharing. 

4.6 Abstract Machines for Querying and Change Management 

As mentioned, Neptune HAM defined not only data modeling primitives but also operations 
for managing change and querying. These are independent dimensions and should be treated 
as separate abstraction machines. The query engine should define how a set-oriented query 
engine attaches to a representation, indexes it, and permits powerful queries. A change man- 
agement abstract machine defines operations on versions, configurations, and transformations. 



-241- 



CONCLUSIONS 
4.7 Link Protocol 

Sun's Link Service and HP New Wave both define a protocol applications can use to set up 
various kinds of cross-application links. HP New Wave appears more powerful in that it would 
permit cross-application (key-board) macros based on the link service and implement common 
system-wide protocols for accessing help, tutorials, and other common services. This is an area 
of potential standardization being covered by the several Frameworks consortia mentioned in 
section 3.6. 

A Hypermedia Standardization Group would complement the Frameworks effort if it concen- 
trated on making some of the services described above available. 

5 Conclusions 

This paper has provided a reference model for comparing hypermedia systems and an archi- 
tecture that isolates design decisions to modules. The implication is that we can consider 
separable subsystems in isolation, then combine the parts to make a whole hypermedia sys- 
tem. 

Based on this analysis, several areas where consensus is possible were isolated including: 
media representations, data model, interchange formats, class libraries (for media types, data 
modeling types, and domain specific types like CAD), user interface toolkit class libraries, a 
standard protocol for hnking, standards for persistent languages, and abstract machines for 
queries and change management. 

Some of these standards exist, some are being pursued by other official or de facto standards 
bodies, and some are new possibilities. While it seems too early to consider standardizing 
today's hypermedia systems with their several limitations, the effort toward building consen- 
sus is helping us to understand these systems better and to identify potential areas where 
standards can help. 



-242- 



APPENDIX A: RELATED STANDARDS AND COMMON FORMATS 

6 Appendix A: Related Standards and Common Formats 

This section lists some common external representations of information used for various pur- 
poses. It is included since it represents a beginning of a section on related stcmdards. It also 
demonstrated some of the breadth of kinds of objects that hypermedia systems will need to 
represent. 

communication protocols 

SCSI -- Small Computer Systems Interface 
external representations for data structures 

XDR -- Sun's external data representation 
device- independent procedural page/screen description formats 

DVI -- for TEX 

ditroff -- for troff 

imPRESS(TM) -- document for printing on an IMAGEN laser printer 
EPS -- Encapsulated Postscript -- generated by Adobe Illustrator (TM) , 
Cricketdraw(TM) , Aldus Freehand(TM) on the Macintosh and Media 
Logic's Artisan(TM) on the Sun; also Display Postscript and 
color versions 

media type interchange formats (specific ''document contents'' like 
characters, raster graphics, geometric graphics, sound, video, 
etc). Note: Several of these representations represent structure 
and content. 
ASCII - text 

DIF -- Document Interchange Format -- used to interchange text and 

formatting instructions across a wide variety of wordprocessors 
and publishing systems 

troff - the standard Unix text processing utility 

DCA -- IBM's Revisable Form Text Document Content Architecture. Many 
popular word processors can store documents in this format 



-243- 



APPENDIX A: RELATED STANDARDS AND COMMON FORMATS 



(including IBM Displaywriter(R) , WordPerfect (R) , Wang(R) , 
MultiMate(TM) , Wordstar2000 (R) , Samna IV (TM) , Of f iceWriter (R) , 
and Microsoft Word(R) can store documents in this format. Does 
not support graphics. 

Scribe 

Tex, LaTex -- popular text formatting language, weak on non-textual 
objects, primitives for tables 
, MIF -- Framemaker's Maker Interchange Format 
Interleaf, Microsoft Word, HyperCard, WordStar, Ventura, ... many 

products provide a way to save and restore their state. 
EDA/VGA/CGA -- bitmap screen sizes/resolutions on different PCs 
X3H3 GKSM -- Graphical Kernal System Metafile (polyline, polymarker, 
text, fill area, cell array, generalized drawing primitive) 
(A second metafile standard provides a way to encode a sq 
sequence of GKS commands. The description of the objects, not 
the image is saved. 

PHIGS 

GIF -- graphic interchange format 
ISO Computer Graphics Metafile 

PICT -- Macintosh standard graphics description format 
pic -- a language for typesetting graphics 

HPGL a popular plotter output format used by many workstation CAD 

programs like AutoCAD 
IGES -- a standard graphics interchange format used by many workstation 

CAD programs 

MacDraw - Macintosh(TM) MacDraw f iles--QuickDraw--toolbox ROM routines 
NTSC -- U.S. etc television format standard for production and 

transmission; Europe uses PAL; HDTV and ACTV are next 

generat ion 



-244- 



APPENDIX B: DOCUMENT LOG 

SMPTE -- Society of Motion Picture and Television Engineers--time code 
for syncing audio, video, film 
document/audio-video representation and interchange formats 

SGML -- ANSI/ISO Standard Generalized Markup Language. Uses markups 

(tags) to create an indirections between intent and rendering. 
Does not support graphics . 
ODIF -- Office Document Interchange Format. ODA distinguishes a logical 

hierarchy and a layout hierarchy 
CD-I -- Compact Disk Interactive, compression/decompression formats 
DVI -- Digital Video Interative. Text, audio, video stills, and video 
motion, at various resolutions, mixed, 
compression/decompression formats 
cad-specific interchange formats 

EDIF -~ Electronic Data Interchange Format 
VHDL -- VHSIC Hardware Description Language 
CIF -- Caltech Interchange Format 
product interchange format 

PDES -- Product Data Exchange Specification 
EDI -- Electronic Data Interchange 

7 Appendix B: Document Log 

The document log lists bibliographies, conference proceedings, key papers, and other docu^ 
ments that are related to the hypermedia standardization effort. 

[1] Jakob Nielsen, "Hypertext Bibliography," Hypermedia, Taylor Graham (ed), 1:1, 1989 
This bibliography references key papers by Bush, Engelbart, Kay, and Nelson; surveys anc 
books by Conklin and Schneiderman; systems like Intermedia, Neptune, KMS, HyperCard 
Notecards, Guide, Object Lens; and other technical papers on hypermedia. 
[2] Proceeding of the ACM SIGPLAN/SIGOA Symposium on Text Manipulation, Portland 



-245- 



T APPENDIX B: DOCUMENT LOG 



Oregon, June 8-10 1981. Available as SIGPLAN Notices 16(6) or SIGOA Newsletter 2(1-2). 

[3] Hypertext'87 Proceedings, ACM press, Chapel Hill, NC, November 13-15, 1987. 

[4] Hypertext'89 Proceedings, ACM press, Pittsburgh, November 5-8, 1989. 

[5] ACM Conference on Document Processing Systems, ACM Press, Santa Fe, New Mexico, 
December 5-9, 1989. 

[6] Bernstein, Jeremy, Frank Halasz, and Tim Oren. "Dexter Hypertext Interchange Format 
(DHIF)-Discussion and Format Specification-version 1.4", unpublished, November 3, 1989. 

[7] Campbell, B. and J. M. Goodman. "HAM: A General Purpose Hypertext Abstract Ma- 
chine," Comm.unications of the ACM, 31:7, July, 1988. 

[8] IBM (1983). Document Content Architecture: Revisable- Form-Text Reference. SC23- 
0758. 

[9] International Organization for Standardization (1986). Standard Generalized Markup 
Language. ISO DIS 8879. 

[10] International Organization for Standardization (1986). Computer Graphics Metaflie. ISO 
IS 8632. 

[11] International Organization for Standardization (1987). Office Document Architecture. 
ISO DIS 8613. 

[12] Knoerdel, J. and Ward Watkins, S. (1984) Document Interchange Format. National 
Bureau of Standards, NBSIR 84-2836. 

[13] Sherman, Mark. "Experiences Interchanging Multimedia Documents using ODA," Con- 
ference on Nev/ Horizons in Electronic Media, International Telecommunications Union, Oc- 
tober 4-7, 1989, Geneva, Switzerland, pp 429-433. 

[14] de La Beaujardiere, Jean-Marie, "Well- Established Document Interchange Formats," 
Document Manipulation and Typography, J.C. van Vliet (ed), Cambridge University Press, 
1988. 

[15] S Mamrak, M. Kaelbling, C. Nicholas, and M. Share. "Chameleon: A System for Solving 
the Data Translation Problem." TR24, Department of Computer and Information Science, 
The Ohio State University, August, 1988. 

-246- 



APPENDICES 



-247- 



I 



I 



Hypermedia Bibliography, 1989 



Paul Kahn, 

Institute for Research in Information and Scholarship 
Brown University, Box 1946 
Providence RI 02912 



Since the last time we compiled this bibliography in November 1987 for the Hypertext '87 Workshop, 
there has been an explosion of hypertext literature. When we started the bibliography project at IRIS in 
1983, we thought it would be possible to collect every book, conference paper and journal article on the 
subject of hypertext. In 1989, that seems an impossible goal. We hope our collection includes a large portion 
of the current literature, but every day we learn of new papers that are not part of our collection. 

This version, prepared for distribution by NIST, contains orJy references to material we have been able to 
collect over the past six years. The reference list differs substantially from the 1987 version. In 1987 there 
just were not that many papers focused entirely on hypertext, so we included in the bibliography many 
papers that, while only tangentially related to the topic of hypertext, had been influential in helping us 
think about the subject. Now that there are so many papers focused solely on hypertext, we have opted to 
narrow the scope of the bibliography and include only those references that are exactly on the topic. 

A longer version of this bibliography, containing the following list plus an annotated list of selected sources 
is available for $3.00 from IRIS (Brown University, Box 1946, Providence RI 02912). 

This bibliography represents a collaborative effort of not only members of the IRIS staff, but also of a num- 
ber of others who have worked on compiling bibliographies, most notably John Leggett (Texas A&M), Jakob 
Nielson (Technical University of Denmark), and Rosemary Simpson (Boston Computer Society). 

The list of references below is arranged alphabetically by first author. 



Agosti, Maristella. "Is Hypertext A New Model of 
Information Retrieval?" Proceedings of the 12th 
International Online Information Meeting. 
December 6-8, 1988, London, England. New Jersey: 
Learned Information, 1988. 57-62. 

Akscyn, Robert M., Donald L. McCracken and Elise 
A. Yoder. "KMS: A Distributed Hypermedia 
System for Managing Knowledge in Organizations." 
Communications of the ACM, Vol. 31, No. 7 (July 
1988): 820-835. 

Akscyn, Robert M. and Donald L. McCracken. "The 
ZOG Approach to Database Management." Pro- 
ceedings of the Trends and Applications Con- 
ference: Making Databases Work. Gaithersburg, 
MD, May, 1984. 

Alexander, George. "Knowledge Management 
Systems from Scribe: Hypertext for Groups." The 
Seybold Report on Publishing Systems, Vol. 18, No. 
12 (1989): 11-17. 

Allen, Todd, Robert Nix and Alan Perlis. "PEN: A 
Hierarchical Document Editor." Proceedings of the 
ACM SIGPLAN/SIGOA Conference on Text Ma- 
nipulation. Portland, Oregon, June, 1981. 



Allinson, Lesley and Nick Hammond. "A Learning 
Support Environment: The Hitch Hikers Guide." in 
Hypertext: Theory into Practice, Ray McAleese, 
(editor). Norwood, NJ: Ablex Publishing 
Corporation, 1989. 62-74. 

Alschuler, Liora. "Hand-Crafted Hypertext- 
Lessons from the ACM Experiment." in The Society 
of Text: Hypertext, Hypermedia, and the Social 
Construction of Information, Edward Barrett, 
(editor). Cambridge, MA: The MIT Press, 1989. 343- 
361. 

Ambron, Sueann and Kristina Hooper. Interactive 
Multimedia. Redmond, WA: Microsoft Press, 1988. 

Backer, D. and Stephen Gano. "Dynamically 
Alterable Videodisk Displays." Proceedings of 
Graphics Interface 82. Toronto, Canada, May 1982. 

Baird, Patricia and Mark Percival. "Glasgow On- 
Line: Database Development using Apple's 
HyperCard." in Hypertext: Theory into Practice, 
Ray McAleese, (editor). Norwood, NJ: Ablex 
Publishing Corporation, 1989. 75-92. 



Hypermedia Bibliography 



-249- 



October 1989 



Barrett, Edward. The Society of Text: Hypertext, 
Hypermedia, and the Social Construction of 
Information. Cambridge, MA: The MIT Press, 1989. 

Baskir\, A. B. "Logic Nets: Variable-Valued Logic 
Plus Semantic Networks." International journal on 
Policy Analysis and Information Systems, Vol. 4 
(1980): 269. 

Beeman, William O., Kenneth T. Anderson, Gail 
Bader, James Larkin, Anne P. McClard, Patrick }. 
McQuillan and Mark Shields. "Hypertext and 
Pluralism: From Lineal to Non-linea! Thinking." 
Hypertext '87 Papers. November 13-15, 1987, 
Chapel Hill, NC. New York: ACM, 1989. 67-88. 

Beeman, William O., Kenneth T. Anderson, Gail 
Bader, james Larkin, Anne P. McClard, Patrick 
McQuillan and Mark Shields. Intermedia: A Case 
Study of Innovation in Higher Education. Final 
Report to the AnnenbergjCPB Project, IRIS, Brown 
University, Providence, RI, 1988. 

Begeman, Michael L. and Jeff Conklin. "The Right 
Tool for the Job." Byte, Vol. 12, No. 10 (October 
- 1988): 255-266. 

Begeman, Michael L., P. Cook, Clarence Ellis, M. 
Graf, G. Rein and T. Smith. "PROJECT NICK: 
Meetings Augmentation and Analysis." Computer- 
Supported Cooperative Work (CSCW '86) Pro- 
ceedings. December 3-5, Austin, TX, 1986. 

Bernstein, Mark. "The Bookmark and the Compass: 
Orientation Tools for Hypertext Users," ACM 
SIGOIS Bulletin. Robert B. Allen, (editor). Vol. 9, 
No. 4 (October 1988): 34-45. 

Bender, Walter. "Imaging and Interactivity." 
Fifteenth joint Conference on Image Technology. 
November, Tokyo, Japan, 1984. 

Bernstein, Mark (editor). AI and Hypertext: Issues 
and Directions. AAAI-88 Workshop proceedings, 
August 1988, St. Paul, MN, Watertown, MA: 
Eastgate Systems, Inc., 1988. 

Bhargava, Hemant, Michael Bieber and Steven O. 
Kimbrough. "OONA, MAX and the WYWWYWI 
Principle: Generalized Hypertext and Model 
Management in a Symbolic Programming 
Environment." Proceedings of ICIS '88. 179-191. 

Bieber, Michael and Steven O. Kimbrough. On 
Generalizing the Concept of Hypertext, Technical 
Report BCCS-89-03, Computer Science Department, 
Boston College, Chestnut Hill, MA, September 
1989. 



Bigelow, James and Victor Riley. "Manipulating 
Source Code in Dynamic Design." Hypertext '87 
Papers. November 13-15, 1987, Chapel Hill, NC. 
New York: ACM, 1989. 397-408. 

Biggerstaff, Ted, Clarence Ellis, Frank G. Halasz, 
C. Kellogg, C. Richter and D. Webster. "In- 
formation Management Challenges in the Software 
Design Process." Database Engineering, Vol. 10, No. 
1 (March, 1987): 24-31. 

Binder, Carl. "The Promise of a Paperless 
Workplace." Optical Insights, (Fall 1987). 

Binder, Carl, "The Window Book Technology." 
Boston Computer Society Training and Doc- 
umentation Newsletter, (Fall 1986). 

Bjorklund, Lisbeth, Birgitta Olander and Linda C. 
Smith. "The Personal Hypercatalog." Annual 
Meeting of the American Society for Information 
Science. October 30-November 1, 1989, Washington, 
DC, 1989. 

Blair, David C. and M. E. Maron. "An Evaluation of 
Retrieval Effectiveness for a Full-Text Document- 
Retrieval System." Communications of the ACM, 
Vol. 28, No. 3 (March 1985): 289-299. 

Bolt, Richard A. Spatial Data-Management, 
DARPA Report, MIT Architecture Machine Group, 
Cambridge, MA, 1979. 

Bolter, Jay David and Michael Joyce. "Hypertext 
and Creative Writing." Hypertext '87 Papers. 
November 13-15, 1987, Chapel Hill, NC. New 
York: ACM, 1989. 41-50. 

Bourne, John R., Jeff Cantwell, Authur J. Brodersen, 
Brian Antao, Antonis Koussis and Yen-Chun Huang. 
"Intelligent Hypertutoring in Engineering." 
Academic Computing, (September 1989): 18-20, 42- 
48. 

Bovey, J. D. and Peter J. Brown. "Interactive 
Document Display and its Use in Information 
Retrieval." journal of Documentation, Vol. 43, No. 2 
(June 1987): 125-137. 

Brockmann, R. John, William Horton and Keven 
Brock. "Limited Freedom: Linear Reflections on 
Nonlinear Texts." in The Society of Text: Hy- 
pertext, Hypermedia, and the Social Construction 
of Information, Edward Barrett, (editor). 
Cambridge, MA: The MIT Press, 1989. 162-205. 



Hypermedia Bibliography NISI Version 



-250- 



January 1990 



Brown, John Seely. Notes Concerning Design 
Functionality, Issues and Philosophy for an 
AuthoringLand, Xerox Palo Alto Research Center, 
Palo Alto, CA, February 1982. 

Brown, John Seely. "Process versus Product: A 
Perspective on Tools for Communal and Informal 
Electronic Learning." in Education in the Electronic 
Age: A Report from the Learning Lab, 
WNET/Thirteen Learning Lab. New York: WNET, 
1983. 41-58. 

Brown, Peter J. "Interactive Documentation." 
Software-Practice and Experience, Vol. 16, No. 3 
(March 1986): 291-299. 

Brown, Peter J. "A Simple Mechanism for the 
Authorship of Dynamic Documents." in Text 
Processing and Document Manipulation: Proceedings 
of the International Conference, J. C. van Vliet, 
(editor). Cambridge: Cambridge University Press, 
1986. 34-42. 

Brown, Peter J. "Viewing Documents on a Screen." in 
CD-ROM: The New Papyrus, Steve Lambert and 
Suzanne Ropiequet, (editors). Redmond, WA: 
Microsoft Press, 1986. 175-186. 

Brown, Peter J. "On-Line Documentation." in State 
of the Art in Computer Graphics, Earnshaw, 
(editor). Springer-Verlag, 1987. 

Brown, Peter J. "Turning Ideas into Products: The 
Guide System." Hypertext '87 Papers. November 
13-15, 1987, Chapel Hill, NC. New York: ACM, 
1989. 33-40. 

Brown, Peter J. "Hypertext: The Way Forward." in 
Document Manipulation and Typography, J. C. van 
Vliet, (editor). Cambridge: Cambridge University 
Press, 1988. 183-191. 

Brown, Peter J. "Linking and Searching in 
Hypertext." EP-odd, Vol. 1, No. 1 (1988): 45-53. 

Buchert, R. F., K. H. Evers and P. R. Santucci. 
"SADT/Saint Simulation Technique." National 
Aerospace and Electronics Conference Proceedings. 
1981, 

Bush, Vannevar. "As We May Think." Atlantic 
Monthly, Vol. 176, No. 1 (July 1945): 101-108. 

Bush, Vannevar. "Memex Revisited." in Science Is 
Not Enough by Vannevar Bush. New York: 
WilUam Morrow, 1967. 75-101. 



Hypermedia Bibliography NIST Version 



Campbell, Brad and Joseph M. Goodman. "HAM: A 
General Purpose Hypertext Abstract Machine." 
Communications of the ACM, Vol. 31, No. 7 (July 
1988): 856-861. 

Carlson, Patricia Ann. "Hypertext and Intelligent 
Interfaces for Text Retrieval." in The Society of 
Text: Hypertext, Hypermedia, and the Social 
Construction of Information, Edward Barrett, 
(editor). Cambridge, MA: The MIT Press, 1989. 59- 
76. 

Carmody, Steve, W. Gross, Theodor H. Nelson, 
David E. Rice and Andries van Dam. "A Hypertext 
Editing System for the /360." in Pertinent Concepts 
in Computer Graphics, M. Faiman and J. 
Nievergelt, (editors). University of Illinois Press, 
1969. 63-88. 

Carr, C. "Hypertext: A New Training Tool?" 
Educational Technology, Vol. 28, No. 8 (1988): 7-11. 

Carroll, John M. and Amy P. Aaronson. "Learning by 
Doing with Simulated Intelligent Help." in The 
Society of Text: Hypertext, Hypermedia, and the 
Social Construction of Information, Edward Barrett, 
(editor). Cambridge, MA: The MIT Press, 1989. 423- 
452. 

Cashin, P., M. Robinson and D. Yates. "Experience 
with SCRAPBOOK, A Non-Formatted Data Base 
System." Proceedings IFIPS Congress, 1973. 

Catano, James V. "Poetry and Computers: 
Experimenting with the Communal Text." Com- 
puters and the Humanities, Vol. 13 (1979): 269-275. 

Catlin, Timothy, Paulette E. Bush and Nicole 
Yankelovich. "InterNote: Extending a Hypermedia 
Framework to Support Annotative Collaboration." 
Hypertext '89 Proceedings. November 5-7, 1989, 
Pittsburgh, PA. New York: ACM, 1989. 365-378. 

Catlin, Timothy J. O. and Karen E. Smith. "Anchors 
for Shifting Tides: Designing a 'Seaworthy' 
Hypermedia System." Proceedings of the 12th 
International Online Information Meeting. 
December 6-8, 1988, London, England. Oxford and 
New Jersey: Learned Information, 1988. 15-25. 

Charney, Davida. "Comprehending Non-Linear 
Text: The Role of Discourse Cues and Reading 
Strategies." Hypertext '87 Papers. November 13-15, 
1987, Chapel Hill, NC. New York: ACM, 1989. 109- 
120. 

Charney, Davida and Lynne M. Reder. "Designing 
Interactive Tutorials for Computer Users." Human- 
Computer Interaction, Vol. 2, No. 4 (1986): 297-317. 

-251- January 1990 



Chignell, Mark H. and Richard M. Lacy. "Project 
Jefferson: Integrating Research and Instruction." 
Academic Computing, (September 1988): 12-17, 40. 

Christodoulakis, Stavros and Stephan Graham. 
"Browsing Within Time-Driven Multimedia 
Documents." Conference on Office Information 
Systems. Robert B. Allen, (editor). March 23-25, 

1988, Palo Alto, CA. New York: ACM, 1988. 219- 
227. 

Claassen, W. T. and T. J. D. Bothma. "Structuring 
Diverse Types of Information in Hypertext: The 
Case of Biblical Information." Proceedings of the 
12th. International Online Information Meeting. 
December 6-8, 1988, London, England. Oxford and 
New Jersey: Learned Information, 1988. 83-90. 

Clitherow, Peter, Doug Riecken and Michael 
Muller. "VISCAR: A System for Inference and 
Navigation of Hypertext." Hypertext '89 
Proceedings. November 5-7, 1989, Pittsburgh, PA. 
New York: ACM, 1989. 293-304. 

Collier, George H. "Thoth-II: Hypertext with 
Explicit Semantics." Hypertext '87 Papers. Novem- 
ber 13-15, 1987, Chapel Hill, NC. New York: ACM, 

1989. 269-290. 

Combelic, D. "User Experience with New Software 
Methods (SADT)." Proceedings of the National 
Computer Conference, 1978. 631-633. 

Conklin, Jeff. A Survey of Hypertext, MCC 
Technical Report STP-356-86, Rev. 2. MCC 
Software Technology Program, Austin, TX, 
December 3, 1986. 

Conklin, Jeff. "Hypertext: An Introduction and 
Survey." IEEE Computer, Vol. 20, No. 9 (September, 
1987): 17-41. 

Conklin, Jeff and Michael L. Begeman. "gIBIS: A 
Hypertext Tool for Team Design Deliberation." 
Hypertext '87 Papers. November 13-15, 1987, 
Chapel Hill, NC. New York: ACM, 1989. 247-252. 

Conklin, Jeff and Michael Begeman. "gIBIS: A Tool 
for All Reasons." Journal of American Society for 
Information Science, Vol. 40, No. 3 (May 1989): 200- 
213. 

Consens, Mariano P. and Alberto O. Mendelzon. 
"Expressing Structural Hypertext Queries in 
GraphLog." Hypertext '89 Proceedings. November 
5-7, 1989, Pittsburgh, PA. New York: ACM, 1989. 
269-292. 



Cooke, Peter and Ian Williams. "Design Issues in 
Large Hypertext Systems for Technical Doc- 
umentation." in Hypertext: Theory into Practice, 
Ray McAleese, (editor). Norwood, NJ: Ablex 
Pubhshing Corporation, 1989. 93-104. 

Corda, U. and G. Facchetti. "Concept Browser: A 
System for Interactive Creation of Dynamic 
Documentation." in Text Processing and Document 
Manipulation: Proceedings of the International 
Conference, J. C. van Vliet, (editor). Cambridge: 
Cambridge University Press, 1986. 

Crane, Gregory. "From the Old to the New: 
Integrating Hypertexts into Traditional Schol- 
arship." Hypertext '87 Papers. November 13-15, 
1987, Chapel Hill, NC. New York: ACM, 1989. 51- 
56. 

Croft, W. Bruce and Howard Turtle. "A Retrieval 
Model Incorporating Hypertext Links." Hypertext 
'89 Proceedings. November 5-7, 1989, Pittsburgh, 
PA. New York: ACM, 1989. 213-224. 

Crouch, Donald B., Carolyn J. Crouch and Glenn 
Andreas. "The Use of Cluster Hierarchies in 
Hypertext Information Retrieval." Hypertext '89 
Proceedings. November 5-7, 1989, Pittsburgh, PA. 
New York: ACM, 1989. 225-238. 

Dede, Christopher J. "Empowering Environments, 
Hypermedia, and Micro worlds." The Computing 
Teacher, Vol. 15, No. 3 (November 1987): 20-26. 

Delisle, Norman and Mayer Schwartz. "Contexts — 
A Partitioning Concept for Hypertext." Computer- 
Supported Cooperative Work (CSCW '86) 
Proceedings. December 3-5, Austin, TX, 1986. 147- 
152. 

Delisle, Norman and Mayer Schwartz. Neptune: A 
Hypertext System for CAD Applications, CR-85- 
50. Tektronix Computer Research Laboratory, 
Beaverton, OR, January 1986. 

DeRose, Steven J. "Expanding the Notion of Links." 
Hypertext '89 Proceedings. November 5-7, 1989, 
Pittsburgh, PA. New York: ACM, 1989. 249-258. 

DeYoung, Laura. "Hypertext Challenges in the 
Auditing Domain." Hypertext '89 Proceedings. 
November 5-7, 1989, Pittsburgh, PA. New York: 
ACM, 1989. 169-180. 

diSessa, Andrea A. "A Principled Design for an 
Integrated Computational Environment." Human- 
Computer InteracHon, Vol. 1 (1985): 1-47. 



Hypermedia Bibliography NISI Version 



-252- 



January 1990 



diSessa, Andrea A. and Harold Abelson. "Boxer: A 
Reconstructable Computational Medium." Com- 
munications of the ACM, Vol. 29, No. 9 (September, 
1986): 859-868. 

Doland, Virginia M. "The Hermeneutics of 
Hypertext." Proceedings of the 12th International 
Online Information Meeting. December 6-8, 1988, 
London, England. Oxford and New Jersey: Learned 
Information, 1988. 75-82. 

Doland, Virginia M. "Hypermedia as an 
Interpretive Act." Hypermedia, Vol. 1, No. 1 
(Spring 1989): 6-19. 

Duffy, Thomas M., Brad Mehlenbacher and Jim 
Palmer. "The Evaluation of Online Help Systems: 
A Conceptual Model." in The Society of Text: 
Hypertext, Hypermedia, and the Social 
Construction of Information, Edward Barrett, 
(editor). Cambridge, MA: Tl\e MIT Press, 1989. 362- 
387. 

Duncan, Elizabeth B. "Structuring Knowledge Bases 
for Designers of Learning Materials." Hypermedia, 
Vol. 1, No. 1 (Spring 1989): 20-33. 

Duncan, Elizabeth B. "A Faceted Approach to 
Hypertext?" in Hypertext: Theory into Practice, 
Ray McAleese, (editor). Norwood, NJ: Ablex 
Publishing Corporation, 1989. 157-163. 

Edwards, Deborah M. and Lynda Hardman. "'Lost 
in Hyperspace': Cognitive Mapping and 
Navigation in a Hypertext Environment." in 
Hypertext: Theory into Practice, Ray McAleese, 
(editor). Norwood, NJ: Ablex Publishing 
Corporation, 1989. 105-125. 

Egan, Dennis E., Joel R. Remde,. Thomas K. 
Landauer, Carol C. Lockbaum and Louis M. Gomez. 
"Behavioral Evaluation and Analysis of a 
Hypertext Browser." Proceedings of the Annual 
Meeting of the American Educational Research 
Association. April 30-May 4, 1989, Austin, TX. 205- 
210. 

Egan, Dennis E., Joel R. Remde, Louis M. Gomez, 
Thomas K. Landauer, Jennifer Eberhardt and Carol 
C. Lochbaum. "Formative Design Evaluation of 
SuperBook." ACM Transactions on Information 
Systems, Vol. 7, No. 1 (January 1989): 30-57. 

Ehrlich, K. and Janet H. Walker. "High 
Functionality, Information Retrieval, and the 
Document Examiner." in Personalized Intelligent 
Information Systems, Report on a Workshop 
(Breckenridge, CO), Fischer, G. and H. Nieper, 
(editors). 1987. 

Hypermedia Bibliography NIST Version 



Engelbart, Douglas C. "A Conceptual Framework 
for the Augmentation of Man's Intellect." in Vistas 
in Information Handling, Volume I, P. D. Howcrton 
and D. C. Weeks, (editors). Washington, D.C.: 
Spartan Books, 1963. 1-29. 

Engelbart, Douglas C. "Coordinated Information 
Services for a Discipline or Mission-Oriented 
Community." Second Annual Computer Com- 
munications Conference. San Jose, CA, January, 1973. 

Engelbart, Douglas C. "Fesign Considerations for 
Knowledge Workshop Terminals." AFIPS Con- 
ference Proceedings - 1973 National Computer 
Conference and Exposition. June 4-8, 1987, New 
York, NY. Montvale, NJ: AFIPS Press, 1973. 221- 
227. 

Engelbart, Douglas C. "Toward Integrated 
Evolutionar)^ Office Automation Systems." Pro- 
ceedings of the International Engineering Man- 
agement Conference. October 16-18, Denver, CO, 
1978. 

Engelbart, Douglas C. "Evolving the Organization 
of the Future: A Point of View." Emerging Office 
Systems. Robert M. Landau and James H. Blair, 
(editors), 1982. 287-297. 

Engelbart, Douglas C. "Authorship Provisions in 
Augment." Proceedings of the 1984 COMPCON 
Conference (COMPCON '84 Digest). February 27- 
March 1, 1984, San Francisco, CA. IEEE Computer 
Society Press, Spring, 1984. 465-472. 

Engelbart, Douglas C. "Collaboration Support 
Provisions in Augment." Proceedings of the AFIPS 
Office Automation Conference (OAC '84 Digest). 
February, 1984, Los Angeles, CA, 1984. 51-58. 

Engelbart, Douglas C. and William K. English. "A 
Research Center for Augmenting Human Intellect." 
AFIPS Conference Proceedings, 1968 Fall Joint 
Computer Conference. December 9-11, 1968, San 
Francisco, CA. Montvale, NJ: AFIPS Press, Fall 
1968. 395-410. 

Engelbart, Douglas C. with Kristina Hooper. "The 
Augmentation System Framework." in Interactive 
Multimedia, Sueann Ambron and Kristina Hooper, 
(editors). Redmond, WA: Microsoft Press, 1988. 15- 
32. 

Engelbart, Douglas C, Richard W. Watson and 
James C. Norton. "The Augmented Knowledge 
Workshop." AFIPS Conference Proceedings, 1973 
National Computer Conference and Exposition. June 
4-8, 1973, New York, NY. Montvale, NJ: AFIPS 
Press, 1973.9-21. 

-253- January 1990 



English, William K., Douglas C. Engelbart and M. 
L. Berman. "Display-Selection Techniques for Text 
Manipulation/' IEEE Transactions on Human 
Factors and Electronics, Vol. 8, No. 1 (March 1967): 
5-15. 

Evenson, Shelly, John Rheinfrank, Fitch 
Richardsonsmith and Wendy Wulff. "Towards a 
Design Language for Representing Hypermedia 
Cues." Hypertext '89 Proceedings. November 5-7, 
1989, Pittsburgh, PA. New York: ACM, 1989. 83-92. 

Fairchiid, Kim ¥., Steve E. Poltrock and George W. 
Furnas, "SemNet: Three-dimensional Graphic 
Representations of Large Knowledge Bases." in 
Cognitive Science and its Applications for Human- 
Computer Interaction, R. Guindon, (editor). 
Hillsdale, NJ: Lawrence Erlbaum Associates, in 
press. 

Feiner, Steven. "Interactive Documents." in Design 
in the Information Environment, P. Whitney and C. 
Kent, (editors). New York: Alfred Knopf, 1985. 118- 
132. 

Feiner, Steven. "Seeing the Forest for the Trees: 
Hierarchical Display of Hypertext Structure." 
Conference on Office Information Systems. March 
23-25, 1988, Palo' Alto, CA. New York: ACM. 205- 
212. 

Feiner, Steven, Sandor Nagy and Andries van Dam, 
"An Experimental System for Creating and 
Presenting Interactive Graphical Documents." ACM 
Transactions on Graphics, Vol. 1, No. 1 (January 
1982): 59-77. 

Feiner, Steven, Sandor Nagy and Andries van Dam. 
"An Integrated System for Creating and Presenting 
Complex Computer -Based Documents." Computer 
Graphics, Vol. 15, No. 3 (August 1981): 181-189. 

Feiner, Steven, Sandor Nagy and Andries van Dam. 
"Online Documents Combining Pictures and Texts." 
Proceedings of the International Conference on 
Research Trends in Document Preparation Systems. 
February 27-28, Lausanne, Switzerland. Lausanne 
and Zurich: Swiss Institutes of Technology, 1981. 1- 
4. 

Fischer, Gerhard, Raymond McCall and Anders 
Morch. "JANUS: Integrating Hypertext with a 
Knowledge-Based Design Environment." Hypertext 
'89 Proceedings. November 5-7, 1989, Pittsburgh, 
PA. New York: ACM, 1989. 105-118. 



Fish, Robert S., Robert E. Kraut, Mary D. P. Leland 
and Michael Cohen. "Quilt: A Collaborative Tool 
for Cooperative Writing." ACM SIGOIS Bulletin. 
Robert B. Allen, (editor). (March 1988): 30-37. 

Foss, Carolyn L. "Effective Browsing in Hypertext 
Systems." Proceedings of the Conference on User- 
Oriented Content-Based Text and Image Handling 
(RIAO 88). March 21-24, MIT, Cambridge MA. 
Centre de Hautes Etudes Internationales 
d'informatique Documentaire, 1988. 83-98. 

Foster, Edward. "Outliners: A New Way of 
Thinking." Personal Computing, (May, 1985): 74. 

Foster, Gregg and Mark Stefik. "Cognoter, Theor}' 
and Practice of a Collaborative Tool." Computer- 
Supported Cooperative Work (CSCW '86) Pro- 
ceedings. December 3-5, Austin, TX, 1986. 7-15. 

Frisse, Mark. "From Text to Hypertext." Byte, 
(October 1988): 247-253. 

Frisse, Mark E. "Searching for Information in a 
Hypertext Medical Handbook." Communications of 
the ACM, Vol. 31, No. 7 (July 1988): 880-886. 

Frisse, Mark E. and Steve B. Cousins. "Information 
Retrieval from Hypertext: Update on the Dynamic 
Medical Handbook Project." Hypertext '89 
Proceedings. November 5-7, 1989, Pittsburgh, PA. 
New York: ACM, 1989. 199-212. 

Furuta, Richard and P. David Stotts. 
"Programmable Browsing Semantics in Tellis." 
Hypertext '89 Proceedings. November 5-7, 1989, 
Pittsburgh, PA. New York: ACM, 1989. 27-42. 

Garg, Pankaj K. "Abstraction Mechanisms in Hy- 
pertext." Communications of the ACM, Vol. 31, No. 
7 (July 1988): 862-870. 

Garg, Pankaj K. and Walt Scacchi. "Composition of 
Hypertext Nodes." Proceedings of the 11th 
International Online Information Meeting. De- 
cember 6-8, 1988, London, England. Oxford and New 
Jersey: Learned Information, 1988. 63-73. 

Garg, Pankaj K. and Wait Scacchi. "A Hypertext 
System to Manage Software Life Cycle Documents." 
7.1st Hawaii International Conference on Systems. 
Honolulu HI, 1987. 

Garg, Pankaj K. and Walt Scacchi, "On Designing 
Intelligent Hypertext Systems for information 
Management in Software Engineering." Hypertext 
'87 Papers. November 13-15, 1987, Chapel Hill, 
NC. New York: ACM, 1989. 409-432. 



Hypermedia Bibliography NISI Version 



-254- 



January 1990 



Garrett, L. Nancy and Karen E. Smith. "Building a 
Timeline Editor from Prefab Parts: The Ar- 
chitecture of an Object-oriented Application." 
Proceedings of the Conference on Object-Oriented 
Programming Systems, Languages and Applications 
(OOPSLA '86). September 29-October 2, Portland, 
Oregon,1986. 202-213. 

Garrett, L. Nancy, Karen E. Smith and Norman 
Meyrowitz. "Intermedia: Issues, Strategies, and 
Tactics in the Design of a Hypermedia Document 
System." Computer- Supported Cooperative Work 
(CSCW '86) Proceedings. December 3-5, Austin, TX, 
1986. 163-174. 

Gaulding, Jill and Boris Katz. "Using 'Word- 
Knowledge' Reasoning for Question Answering." in 
The Society of Text: Hypertext, Hypermedia, and 
the Social Construction of Information, Edward 
Barrett, (editor). Cambridge, MA: The MIT Press, 
1989. 403-422. 

Glushko, Robert J. "Design Issues for Multi- 
Document Hypertexts." Hypertext '89 Proceedings. 
November 5-7, 1989, Pittsburgh, PA. New York: 
ACM, 1989. 51-60. 

Glushko, Robert J., M. D. Weaver, T. A. Coonan and 
}. E. Lincoln. "Hypertext Engineering: Practical 
Methods for Creating a Compact Disc En- 
cyclopedia." Proceedings of the ACM Conference on 
Document Processing Systems. December 5-9, 1988, 
Santa Fe, New Mexico. New York: ACM, 1988. 11- 
19. 

Goodman, Danny. The Complete HyperCard Hand- 
book. New York: Bantam Books, 1987. 

Greenes, Robert A. "Knowledge Management as an 
Aid to Medical Decision Making and Education: 
The Explorer-1 System." Proceedings MEDINFO 
'86. Elsevier Science Publishers B.V., 1986. 895-899. 

Greenes, Robert A. "Toward More Effective 
Radiologic Consultation: Design of a Desktop 
Workstation to Aid in the Selection and In- 
terpretation of Diagnostic Procedures." Proceedings 
Eighth Conference on Computer Applications in 
Radiology. May 1984, St. Louis, MO. 553-562. 

Gregory, Roger. "Xanadu — Hypertext from the 
Future." Dr. Dobb's Journal, No. 75 (January, 1983): 
28-35. 



Grico, Roger A. "Online Information: What Do 
People Want? What Do People Need?" in The 
Society of Text: Hypertext, Hypermedia, and the 
Social Construction of Information, Edward Barrett, 
(editor). Cambridge, MA; The MIT Press, 1989. 22- 
44. 

Gullichsen, Eric, D. D'Souza, P. Lincoln and T. 
Casey. The PlaneTextBook, STP-333-86(P). MCC 
Software Technology Program, Austin, TX, 1986. 

Halasz, Frank G. ""NoleCards: A Multimedia Idea 
Processing Environment." in Interactive Mul- 
timedia, Sueann Ambron and Kristina Hooper, 
(editors). Redmond, Vv'A: Microsoft Press, 1988. 105- 
110. 

Halasz, Frank G. "Reflections on Notecards: Seven 
Issues for the Next Generation of Hypermedia 
Systems." Communications of the ACM, Vol. 31, 
No. 7 (July 1988): 836-855. 

Halasz, Frank G., Thomas P. Moran and Randall H. 
Trigg. "NoteCards in a Nutshell." Proceedings of 
the CHI and GI '87 Conference on Human Factors in 
Computing Systems. J. M. Carroll and P. P. Tanner, 
(editors). April 1987, Toronto. New York: ACM, 
1987. 45-52. 

Hammvi/ohner, Rainer and Ulrich Thiel. "Content- 
Oriented Relations Between Text Units — A Struc- 
tural Model for Hypertexts." Hypertext '87 Papers. 
November 13-15, 1987, Chapel Hill, NC. New 
York: ACM, 1989. 155-174. 

Hardman, Lynda. "Evaluating the Usability of the 
Glasgow Online Hypertext." Hypermedia, Vol. 1, 
No. 1 (Spring 1989): 34-63. 

Harland, J.S. "Human Factors Engineering and 
Interface Development: A Hypertext Tool Aiding 
Prototyping Activity." in Hypertext: Theory into 
Practice, Ray McAleese, (editor). Norwood, NJ: 
Ablex Publishing Corporation, 1989. 126-137. 

Harvey, Greg. Understanding HyperCard. Alame- 
da, CA: SYBEX, Inc., 1988. 

Hayes, Phil and Jeff Pepper. "Towards an 
Integrated Maintenance Advisor." Hypertext '89 
Proceedings. November 5-7, 1989, Pittsburgh, PA. 
New York: ACM, 1989. 119-128. 

Herot, C, R. Carling, M. Friedell and D. Kramlich. 
"A Prototype Spatial Data Management System." 
Computer Graphics, Vol. 14, No. 3 (July 1980): 63- 
70. 



Hypermedia Bibliography NISI Version 



-255- 



January 1990 



Herrstrom, David S. and David G. Massey. 
"Hypertext in Context." in The Society of Text: 
Hypertext, Hypermedia, and the Social Con- 
struction of Information, Edv^ard Barrett, (editor). 
Cambridge, MA: The MIT Press, 1989. 45-58. 

Hershey, William. "Software Review: Idea 
Processors." Byte, Vol. 10, No. 6 (June, 1985): 337- 
350. 

Hiltz, Starr Roxarme. "The 'Virtual Classroom': 
Using Computer-Mediated CornmianicaHon for 
University Teaching." Journal of Communication, 
(Spring, 1968): 95-104. 

Hiltz, Starr Roxanne and Murray Turoff. The 
Network Nation: Human Communication via 
Computer. Reading, MA: Addison-Wesley Pub- 
lishing Company, Inc., 1978. 

Hjerppe, Roland. "Hypercatalog and Three Meta- 
Schemata for Database Views: Knowledge Or- 
ganizing, Collection Derived, and User Established 
Structures." Online Public Access to Library Files: 
Second National Conference. Janet Kinsella, 
- (editor). Elsevier International Bulletins. 101-110. 

Hjerppe, Roland. "Project HYPERCATalog: Visions 
and Preliminary Conceptions of an Extended and 
Enhanced Catalog." in Intelligent Information 
Systems for the Information Society, B. C. Brookes, 
(editor). Amsterdam: Elsevier Science Publishers, 
1986. 211-232. 

Hodges, Matthew E., Ben H. Davis and Russell M. 
Sasnett. "Investigations in Multimedia Design 
Documentation." in The Society of Text: Hypertext, 
Hypermedia, and the Social Construction of 
Information, Edward Barrett, (editor). Cambridge, 
MA: The MIT Press, 1989. 79-89. 

Irby, Charles H. "Display Techniques for In- 
teractive Text Manipulation." AFIPS Conference 
Proceedings — 1974 National Com.puter Conference 
and Exposition. May 6-10, 1974, Chicago, IL. 
Montvale, NJ: AHPS Press. 247-255. 

Irish, Peggy M. and Randall H. Trigg. "Supporting 
Collaboration in Hypermedia: Issues and 
Experiences." in The Society of Text: Hypertext, 
Hypermedia, and the Social Construction of 
Information, Edward Barrett, (editor). Cambridge, 
MA: The MIT Press, 1989. 90-106. 

Jaffe, Conrade C, Patrick J. Lynch and Arnold W. 
M. Smeulders. "Hypermedia Techniques for Di- 
agnostic Imaging Instniction: Videodisk Echocar- 
diography Encyclopedia." Radiology, Vol. 117, No. 
2 (May 1989): 475-80. 

Hypermedia Bibliography NISI Version 



Jaynes, Joseph T. "Limited Freedom: Linear 
Reflections on Nonlinear Texts." in The Society of 
Text: Hypertext, Hypermedia, and the Social 
Construction of Information, Edward Barrett^ 
(editor). Cambridge, MA: The MIT Press, 1989. 148- 
161. 

Jonassen, D. H. "Hypertext Principles for Text and 
Courseware Design." Educational Psychologist, 
Vol. 21 (1986): 269-292. 

Jones, Henry V*/., III. "Developing and Distributing 
Hypertext Tools: Legal Inputs and Parameters." 
Hypertext '87 Papers. November 13-15, 1987, 
Chapel Hill, NC. New York: ACM, 1989. 367-374. 

Jones, William P. "How Do We Distinguish the 
Hyper from the Hype in Non-linear Text?" 
INTERACT '87. H. J. 

and B. Shackel, (editors). September 1-4, 1987, 
Stuttgart. Elsevier Science Publishers B.V., 1987. 
1107-1113. 

Jordan, Daniel S., Daniel M. Russell, Anne-Marie S. 
Jensen and Russel A. Rogers. "Facilitating the 
Development of Representations in Hypertext with 
IDE." Hypertext '89 Proceedings. November 5-7, 
1989, Pittsburgh, PA. New York: ACM, 1989. 93-104. 

Kacmar, Charles J. "A Process-Oriented Extensible 
Hypertext Architecture." SIGCHI Bulletin, Vol. 
21, No. 1 (July 1989): 98-101. 

Kahn, Paul. "Information Retrieval As 
Hypermedia: An Outline of InterBrowse." 
Proceeding of the Ninth National Online Meeting. 
May 10-12, New York. New York: Learned 
Information, 1988. 131-139. 

Kahn, Paul. "Linking Together Books: Experiments 
in Adapting Published Material into Intermedia 
Documents." Hypermedia, Vol. 1, No. 2 (Summer 
1989): 111-144. 

Kahn, Paul and Norman Meyrowitz. "Guide, 
HyperCard, and Intermedia: A Comparison of 
Hypertext/ Hypermedia Systems." IRIS Technical 
Report, 88-7. Brown University, Providence RI, 
1988. 

Kay, Alan C. "Computer Software." Scientific 
American, Vol. 251, No. 3 (September, 1984): 53-59. 

Kay, Alan C. Personal Dynamic Media, Xerox 
PARC Technical Report SSL-76-1. Xerox Palo Alto 
Research Center, Palo Alto CA, March 1976. 



_256- January 1990 



Kelly, Kirk. "Online Citation Maintenance for 
Literature Publication and Retrieval over Com- 
puter Networks." Teleinformatics 79. Boutmy and 
Danthi ne, (editors). North-Holland Publishing 
Company, 1979. 

Kerr, Elaine and Starr Roxanne Hiltz. Computer- 
Mediated Communication Systems. New York: 
Academic Press, 1982. 

Kibby, M.R. and T. Mayes. "Towards Intelligent 
Hypertext." in Hypertext: Theory into Practice, 
Ray McAleese, (editor). Norwood, NJ: Ablex 
Publishing Corporation, 1989. 164-172. 

Kochen, Manfred. "WISE: A World Information 
Synthesis and Encyclopedia." Journal of Doc- 
umentation, Vol. 28 (1972): 322-343. 

Koo, Richard. "A Model for Electronic Documents." 
ACM SIGOIS Bulletin. Simon Gibbs, (editor). 
(January 1989): 23-33. 

Koved, Larry. Restructuring Textual Information for 
Online Retrieval, Technical Report 11278(#50830). 
IBM T.J. Watson Research Center, Yorktown 
Heights, NY, July 23, 1985. 

Kunkel, Paul. "Hyper Media." International 
Design, (March/ April 1989): 41-43. 

Lambert, Steve and Suzanne Ropiequet. CD ROM: 
The New Papyrus. Redmond, WA: Microsoft Press, 
1986. 

Landow, George P. "Context32: Using Hypermedia 
to Teach Literature." Proceedings of the 1987 IBM 
Academic Information Systems University AEP 
Conference. Milford, Connecticut: IBM Academic 
Information Systems, 1987. 

Landow, George P. Course Assignments Using 
Hypertext: The Example of Intermedia, IRIS, 
Brown University, Providence, RI, 1988. 

Landow, George P. "Hypertext in Literary Ed- 
ucation, Criticism, and Scholarship." Computers 
and the Humanities, Vol. 23 (July 1988): 173-198. 

Landow, George P. "Relationally Encoded Links 
and the Rhetoric of Hypertext." Hypertext '87 
Papers. November 13-15, 1987, Chapel Hill, NC. 
New York: ACM, 1989. 331-344. 

Landow, George P. "The Rhetoric of Hypermedia: 
Some Rules for Authors." Journal of Computing in 
Higher Education, Vol. 1, No. 1 (Spring 1989): 39- 
64. 



Lenat, Douglas B., Alan M. Borning, D. McDonald, 
C. Taylor and Stephen A. Weyer. "Knoesphcre: 
Building Expert Systems with Encyclopedic Knowl- 
edge." Proceedings of the 8th International Joint 
Conference on Artificial Intelligence. Karlsruhe, 
West Germany, 1983. 167-169. 

Lesk, Michael. "What to Do When There's Too 
Much Information." Hypertext '89 Proceedings. 
November 5-7, 1989, Pittsburgh, PA. New York: 
ACM, 1989. 305-318. 

Lewis, Brian T. and Jeffrey D. Hodges. "Shared 
Books: Collaborative Publication Management for 
an Office InformaHon System." COIS 88. March 23- 
25, 1988, Palo Alto, CA. New York: ACM, 1988. 197- 
204. 

Louie, Steven and Robert F. Rubeck. "Hypertext 
Publishing and the Revitalization of Knowledge." 
Academic Computing, Vol. 3, No. 9 (May 1989): 20- 
23, 30-31. 

Lowe, David G. "SYNVIEW: The Design of a 
System for Cooperative Structuring of Information." 
Computer-Supported Cooperative Work (CSCW 
'86) Proceedings. December 3-5, Austin, TX, 1986. 
376-386. 

Luther, Willis and Martin Carter. Management of 
Change and History in a Hypermedia Environment, 
MCC Technical Report HI-1 64-87. June 1987. 

Malone, Thomas W., Kenneth R. Grant, Franklyn 
A. Turbak, Stephen Brobst and Michael D. Cohen. 
"Intelligent Information-Sharing Systems." Com- 
munications of the ACM, Vol. 30, No. 5 (May 1987): 
390-402. 

Mantei, Marilyn and Donald L. McCracken. "Issue 
Analysis with ZOG, A Highly Interactive Man- 
Machine Interface." Proceedings of the First 
International Symposium on Policy Analysis and 
Information Systems, 1979. 

Marchionini, Gary. "Hypermedia and Learning: 
Freedom and Chaos." Educational Technology, Vol. 
27, No. 11 (1988): 8-12. 

Marchionini, Gary and Ben Shneiderman. "Finding 
Facts and Browsing Knowledge in Hypertext 
Systems." IEEE Computer, Vol. 21, No. 1 (January 
1988): 70-79. 

Marshall, Catherine C. "Exploring Representation 
Problems Using Hypertext." Hypertext '87 Papers. 
November 13-15, 1987, Chapel Hill, NC. New 
York: ACM, 1989. 253-268. 



Hypermedia Bibliography NiST Version 



-257- 



January 1990 



Marshall, Catherine C. and Peggy Irish. "Guided 
Tours and On-Line Presentations: How Authors 
Make Existing Hypertext Intelligible for Readers." 
Hypertext '89 Proceedings. November 5-7, 1989, 
Pittsburgh, PA. New York: ACM, 1989. 15-26. 

Maxemchuck, Nick F. and H. A. Wilder. "Virtual 
Editing: I. The Concept." Proceedings of the Second 
International Workshop on Office Information 
Systems. October 13-15, 1982, Couvent Royal de St. 
Maximin. New York: Elsevier North-Holland, 
1982. 

McAleese, Ray. Hypertext: Theory into Practice. 
Norwood, New Jersey: Ablex Publishing Cor- 
poration, 1989. 

McAleese, Ray. "Navigation and Browsing in 
Hypertext." in Hypertext: Theory into Practice, 
Ray McAleese, (editor). Norwood, NJ: Ablex 
Publishing Corporation, 1989. 6-44. 

McCracken, Donald L. and Robert M. Akscyn. 
"Experience with the ZOG Human-Computer 
Interface System." International Journal of Man- 
Machine Studies, Vol. 21, No. 2 (1984): 293-310. 

McCracken, Donald L. and Robert Akscyn. The ZOG 
Approach to Database Management, CS-34-113. 
Carnegie-Mellon University, Pittsburgh, PA. 

McKnight, Cliff, John Richardson and Andrew 
Dillon. "The Authoring of HyperText Documents." 
in Hypertext: Theory into Practice, Ray McAleese, 
(editor). Norwood, NJ: Ablex Publishing 
Corporation, 1989. 138-147. 

Meyrowitz, Norman. "Intermedia: The Ar- 
chitecture and Construction of an Object-Oriented 
Hypertext/Hypermedia System and Applications 
Framework." Proceedings of the Conference on 
Object-Oriented Programing Systems, Languages, 
and Applications (OOPSLA '86). September 29- 
October 2, Portland, Oregon, 1986. 

Meyrowitz, Norman. "The Missing Link: Why 
We're All Doing Hypertext Wrong." in The Society 
of Text: Hypertext, Hypermedia, and the Social 
Construction of Information, Edward Barrett, 
(editor). Cambridge, MA: The MIT Press, 1989. 107- 
114. 

Meyrowitz, Norman. Networks of Scholar's 
Workstations: End-User Computing in a University 
Community, Technical Report 85-3. IRIS, Brown 
University, Providence, RI, June 1985. 

Michel, Stephen. "Guide — A Hypertext Solution." 
CD-ROM Review, (July/ August 1987): 22-24. 

Hypermedia Bibliography NISI Version 



Monty, Melissa L. "Temporal Context and Memory 
for Notes Stored in the Computer." ACM SIGCHI 
Bulletin, Vol. 18, No. 2 (October, 1986): 50-51. 

Monty, Melissa L. and Thomas P. Moran. "A 
Longitudinal Study of Authoring Using Note- 
Cards." ACM SIGCHI Bulletin, Vol. 18, No. 2 
(October, 1986): 59-60. 

Morariu, Janis. "Hypermedia in Instruction and 
Training: The Power and the Promise." Educational 
Technology, Vol. 27, No. 11 (1988): 17-20. 

Moulthrop, Stuart. "Hypertext and 'the 
Hyperreal'." Hypertext '89 Proceedings. November 
5-7, 1989, Pittsburgh, PA. New York: ACM, 1989. 
259-268. 

Negroponte, Nicholas. "Books Without Pages." 
IEEE International Conference on Communications 
IV, 1979. 

Negroponte, Nicholas. "An Idiosyncratic Systems 
Approach to Interactive Graphics." 
ACM/SIGGRAPH Workshop on User-Oriented De- 
sign of Interactive Graphics Systems. Pittsburgh, 
PA, October, 1976. 

Nelson, Theodor H. "The Hypertext." 2 965 
Congress of the International Federation for 
Documentation (FID) Abstracts. 10-15 October 1965, 
Washington DC. 80. 

Nelson, Theodor H. "A File Structure for the 
Complex, the Changing and the Indeterminate." 
Association for Computing Machinery, Proceedings 
of the National Conference, 20th. New York: ACM, 
1965. 84-100. 

Nelson, Theodor H. "Getting it Out of Our System." 
in Information Retrieval: A Critical View, G. 
Schecter, (editor). Washington, D.C.: Thompson 
Book Co., 1967. 191-210. 

Nelson, Theodor H. "As We Will Think." Online 
72: Conference Proceedings of the International 
Conference on Online Interactive Computing. 
September, 1972, Brunei University, Uxbridge, 
England. Uxbridge, England: Online Computer 
Systems Ltd, 1973. 439-454. 

Nelson, Theodor H. "A Conceptual Framework for 
Man-Machine Everything." AFIPS Conference 
Proceedings — 2973 National Computer Conference 
and Exposition, Proceedings. June 4-8, 1973, New 
York, NY. Montvale, NJ: AHPS Press, 1973. M21- 
M26. 



-258- January 1990 



Nelson, Theodor H. "Dream Machines: New 
Freedoms through Computer Screens — A Minority 
Report." in Computer Lib: You Can and Must 
Understand Computers Now, Redmond, WA: 
Microsoft Press, 1987. 

Nelson, Theodor H. "Replacing the Printed Word: 
A Complete Literary System." in Information 
Processing 80, S.H. Lavington, (editor). North- 
Holland Publishing Co., IFIO 1980. 1013-1023. 

Nelson, Theodor H. Literary Machines. Swarth- 
more, PA: T.H. Nelson, 1981. 

Nelson, Theodor H. "A New Home for the Mind." 
Datamation, (March, 1982): 169-180. 

Nelson, Theodor H. "Managing Immense Storage." 
Byte, (January 1988): 225-238. 

Nelson, Theodor H. "All for One and One for All." 
Hypertext '87 Papers. November 13-15, 1987, 
Chapel Hill, NC. New York: ACM, 1989. v-vii. 

Nelson, Theodor H. "Unifying Tomorrow's 
Hypermedia." Proceedings of the 12th In- 
ternational Online Information Meeting. December 
6-8, 1988, London, England. Oxford and New Jersey: 
Learned Information, 1988. 1-7. 

Neuwirth, Christine M. "Techniques of User 
Message Design: Developing a User Message 
System to Support Cooperative Work." in The 
Society of Text: Hypertext, Hypermedia, and the 
Social Construction of Information, Edward Barrett, 
(editor). Cambridge, MA: The MIT Press, 1989. 325- 
342. 

Neuwirth, Christine, David Kaufer, Rick Chimera 
and Terilyn Gillespie. "The Notes Program: A 
Hypertext Applications for Writing from Source 
Texts." Hypertext '87 Papers. November 13-15, 
1987, Chapel Hill, NC. New York: ACM, 1989. 121- 
141. 

Neuwirth, Christine M. and David S. Kaufer. "The 
Role of External Representation in the Writing 
Process: Implications for the Design of Hypertext- 
Based Writing Tools." Hypertext '89 Proceedings. 
November 5-7, 1989, Pittsburgh, PA. New York: 
ACM, 1989. 319-342. 

Newell, Alan, Donald L. McCracken, C. Kamila 
Robertson and Robert M. Akscyn. "ZOG and the 
USS CARL VINSON." Computer Science Research 
Review, (1981): 95-118. 



Hypermedia Bibliography NiST Version 



Nguyen, L. T. and Robert A. Greenes. "A Framework 
for the Use of Computed Links in the EXPLORER-1 
Knowledge Management System." in MEDINFO 86, 
IFIP-IMIA, R. Salamon, B. Blum and M. Jorgcnscn, 
(editors). North-Holland: Elsevier Science 
Publishers B.V., 1986. 891-894. 

Nielsen, Jakob. "Evaluating Hypertext Usability." 
Proceedings of NATO Advanced Research 
Workshop on Designing Hypertext/Hypermedia 
for Learning. July 4-7, 1989, Rottenburg, West 
Germany. 

Nielsen, Jakob. "Online Documentation and Reader 
Annotation." Proceedings 1st International 
Conference on Work with Display Units. May 12- 
15, 1986, Stockholm, Sweden. 526-529. 

Nielsen, Jakob. "Prototyping User Interfaces Using 
an Object-Oriented Hypertext Programming 
System." Proceedings of the NordDATA'89 Joint 
Scandinavian Computer Conference. June 19-22, 
1989, Copenhagen, Denmark. 

Nielsen, Jakob and U. Lyngboek. "Two Field Studies 
of Hypermedia Usability." Proceedings of 
Hypertext 2 Conference. June 29-30, 1989, York, UK. 

Nielson, Jakob. "The Matters that Really Matter 
for Hypertext." Hypertext '89 Proceedings. 
November 5-7, 1989, Pittsburgh, PA. New York: 
ACM, 1989. 239-248. 

Nyce, James M. and Paul Kahn. "Innovation, 
Pragmaticism, and Technological Continuity: 
Vannevar Bush's Memex." Journal of American 
Society for Information Science, Vol. 40, No. 3 (May 
1989): 214-220. 

Oren, Tim. "The Architecture of Hypertexts." 
Hypertext '87 Papers. November 13-15, 1987, 
Chapel Hill, NC. New York: ACM, 1989. 291-306. 

Palay, Andrew J. and Mark S. Fox. "Browsing 
through Databases." in Information Retrieval 
Research, R. N. Oddy, (editor). London: 
Butterworths, 1981. 310-324. 

Parunak, H. Van Dyke. "Hypermedia Topologies 
and User Navigation." Hypertext '89 Proceedings. 
November 5-7, 1989, Pittsburgh, PA. New York: 
ACM, 1989. 43-50. 

Pasquier-Boltuck, Jacques, G. Collaud and J. 
Monnard. "An Object-Oriented Approach to 
Conceptualizing and Programming an Interactive 
System for the Creation and Consultation of 
Electronic Books." WOODMAN '89. May 24-31, 
1989, Pennes-France. 

-259- January 1990 



Pasquier-Boltuck, Jacques, Edward Grossman and G. 
Collaud. "Prototyping an Interactive Electronic 
Book System Using an Object-Oriented Approach." 
Proceedings of ECOOP '88. Spring 1988. 

Pearl, Amy. "Sun's Link Service: A Protocol for 
Open Linking." Hypertext '89 Proceedings. Novem- 
ber 5-7, 1989, Pittsburgh, PA. New York: ACM, 
1989. 137-146. 

Perlman, Gary. "Asynchronous Design/ Evaluation 
Methods for Hypertext Technology Development." 
Hypertext '89 Proceedings. November 5-7, 1989, 
Pittsburgh, PA. New York: ACM, 1989. 61-82. 

Perry, T. S. "Hypermedia: Finally Here." IEEE 
Spectrum, Vol. 24, No. 11 (1987): 38-39. 

Pontecorvo, Michael S. 'Idea Processing - Concepts, 
Extensions and Applications." Sperry Technology 
Symposium Proceedings. May 1986, Gull Lake, MN. 

Pontecorvo, Michael S. An Idea Processing 
Approach to the Development of Knowledge-Based 
Systems, Technical Report No. 18376. Sperry 
Communications Corporate Technology Center, Salt 
Lake City, UT, March 1986. 

Pontecorvo, Michael S. and J. J. Krohnfeldt. "A 
Knowledge-Based Software Development Environ- 
ment for the Support of Rapid Prototyping." Univac 
Technology Review, Vol. 13 (May 1987): 

Potter, Richard L., Mitchell Berman and Ben 
Shneiderman. An Experimental Evaluation of 
Three Touchscreen Strategies within a Hypertext 
Database, CS-TR-2141. University of Maryland 
Computer Science Center, College Park, MD, 
November 1988. 

Potts, Colin and Glenn Bruns. "Recording the 
Reasons for Design Decisions." Proceedings 10th 
International Conference on Software Engineering. 
IEEE Computer Society Press, 1988. 

Price, Lynne A. "Thumb: An Interactive Tool for 
Accessing and Maintaining Text." IEEE Transactions 
on Systems, Man, and Cybernetics, March/April, 
1982. 155-162. 

Rada, Roy. "Writing and Reading Hypertext: An 
Overview." Journal of American Society for 
Information Science, Vol. 40, No. 3 (May 1989): 164- 
171. 

Ragland, Craig. "Hypertext, Hypermedia, and the 
Macintosh." Mac A. P. P. I.E., (August, 1987). 



Hypermedia Bibliography NISI Version 



Ramakrishna, K. "Schematization as an Aid to 
Organizing ZOG Information Nets." Computer 
Science Department, Carnegie-Mellon University, 
1981. 

Ramey, Judith. "Escher Effects in Online Text." in 
The Society of Text: Hypertext, Hypermedia, and 
the Social Construction of Information, Edward 
Barrett, (editor). Cambridge, MA: The MIT Press, 
1989. 388-402. 

Raskin, Jef. "The Hype in Hypertext: A Critique." 
Hypertext '87 Papers. November 13-15, 1987, 
Chapel Hill, NC. New York: ACM, 1989. 325-330. 

Raymond, Darrell R. Personal Data Structuring in 
Videotex, CS-84-7. University of Waterloo, De- 
partment of Computer Science Technology, 
February, 1984. 

Raymond, Darrell R. and Frank Wm Tompa. 
"Hypertext and the Oxford English Dictionary." 
Communications of the ACM, Vol. 31, No. 7 (July 
1988): 871-879. 

Reitman, Walter, Bruce Roberts, Richard W. 
Sauvain, Daniel D. Wheeler and William Linn. 
"AUTONOTE - A Personal Information Storage and 
Retrieval System." Proceedings of the 24th 
National Conference of the ACM. August 26-28, 
1969, New York: ACM, 1969. 67-75. 

Remde, Joel R., Louis M. Gomez and Thomas K. 
Landauer. "SuperBook: An Automatic Tool for 
Information Exploration-Hypertext?" Hypertext 
'87 Papers. November 13-15, 1987, Chapel Hill, 
NC. New York: ACM, 1989. 175-188. 

Robertson, C. Kamila and Robert Akscyn. 
"Experimental Evaluation of Tools for Teaching the 
ZOG Frame Editor." Proceedings of the 
International Conference on Man-Machine Systems. 
Manchester, UK: , July, 1982. 115-123. 

Robertson, C. Kamila, Donald L. McCracken and 
Alan Nevv^ell. The ZOG Approach to Man-Machine 
Communication, CMU-CS-79-148. Department of 
Computer Science, Carnegie-Mellon University, 
Pittsburgh, PA, October 1979. 

Rubens, Philip. "Online Information, Hypermedia, 
and the Idea of Literacy." in The Society of Text: 
Hypertext, Hypermedia, and the Social 
Construction of Information, Edward Barrett, 
(editor). Cambridge, MA: The MIT Press, 1989. 3-21. 

Saffo, P. "What You Need to Know about 
Hypertext." Personal Computing, (December, 1987): 
166-173. 

-260- January 1990 



Savoy, Jacques. "The Electronic Book EBOOKS." 
The International Journal of Man-Machine Studies, 
(in press). 

Scacchi, Walt. "On the Power of Domain-Specific 
Hypertext Environments." Journal of American 
Society for Information Science, Vol. 40, No. 3 (May 
1989): 183-191. 

Schatz, Bruce R. Telesophy: A System for Browsing 
and Sharing Inside a Large Information Space, TM- 
ARH-006-094. Bell Communications Research, 
Morristown, NJ, September 1986. 

Schatz, Bruce R. and Michael A. Caplinger. 
"Searching in a Hyperlibrary." Proceedings Fifth 
International Conference on Data Engineering. 
February 1989, Los Angeles. IEEE. 188-197. 

Schnase, John L. and John J. Leggett. 
"Computational Hypertext in Biological 
Modeling." Hypertext '89 Proceedings. November 5- 
7, 1989, Pittsburgh, PA. New York: ACM, 1989. 181- 
198. 

Scully, John. "The Relationship between Business 
and Higher Education: A Perspective on the 
Twenty-First Century." Educom Bulletin, (Spring, 
1988): 20-24. 

Seybold, P. B. "Tymshare's Augment: Heralding a 
New Era." Seybold Report on Word Processing, Vol. 
1, No. 9 (October 1978): M6. 

Shapiro, Ezra. "A First Look at Dayflo." Byte, Vol. 
9, No. 3 (March 1984): 81-87. 

Shasha, Dennis. "NetBook— A Data Model to 
Support Knowledge Exploration." Proceedings of 
the Eleventh International Conference on Very 
Large Data Bases. Stockholm, August, 1985. 

Shasha, Dennis. "When Does Non-linear Text 
Help?" Proceedings of the Expert Database 
Systems Conference. 1986, New York: ACM, 1986. 

Shipman, Frank III, Jesse Chaney and G. Anthony 
Gorry. "Distributed Hypertext for Collaborative 
Research: The Virtual Notebook System." 
Hypertext '89 Proceedings. November 5-7, 1989, 
Pittsburgh, PA. New York: ACM, 1989. 129-13b. 

Shneiderman, Ben. "User Interface Design and 
Evaluation for an Electronic Encyclopedia." Pro- 
ceedings of the 2nd International Conference on 
Human-Computer Interaction. August, 1987, 
Honolulu, HI. 



Shneiderman, Ben. "User Interface Design for the 
Hyperties Electronic Encyclopedia." Hypertext '87 
Papers. November 13-15, 1987, Chapel Hill, NC. 
New York: ACM, 1989. 199-205. 

Shneiderman, Ben, Dorothy Brethauer, Catherine 
Plaisant and Richard Potter. "Evaluating Three 
Museum Installations of a Hypertext System." 
Journal of American Society for Information Science, 
Vol. 40, No. 3 (May 1989): 172-182. 

Shneiderman, Ben. "Reflections on Authoring, 
Editing, and Managing Hypertext." in The Society 
of Text: Hypertext, Hypermedia, and the Social 
Construction of Information, Edward Barrett, 
(editor). Cambridge, MA: The MIT Press, 1989. 115- 
131. 

Shneiderman, Ben and Greg Kearsley. Hypertext 
Hands-On! Reading, MA: Addison-Wesley, 1989. 

Shneiderman, Ben, Philip Shafer, Roland Simon 
and Linda J. Weldon. Display Strategies for 
Program Browsing: Concepts and an Experiment, 
CAR-TR-192, CS-TR-1635. Department of Computer 
Science, University of Maryland, College Park, 
MD, 1986. 

Shultz, Edward K., Roger W. Brown and J. Robert 
Beck. "Hypermedia in Pathology-The Dartmouth 
Interactive Medical Record Project." American 
Journal of Clinical Pathology, Vol. 91, No. 4, suppl. 
1 (April 1989): S34-38. 

Smith, John B. and Stephen F. Weiss. "Hypertext." 
Communications of the ACM, Vol. 31, No. 7 (1988): 
816-619. 

Smith, John B., Stephen F. Weiss and Gordon J. 
Ferguson. "A Hypertext Writing Environment and 
its Cognitive Basis." Hypertext '87 Papers. 
November 13-15, 1987, Chapel Hill, NC. New 
York: ACM, 1989. 195-214. 

Smith, John B., Stephen F. Weiss, Gordon J. 
Ferguson, Jay David Bolter, M. Lansman and D. V. 
Beard. WE; A Writing Environment for Pro- 
fessionals, 86-025. University of North Carolina, 
Department of Computer Science, Chapel Hill, NC, 
August, 1986. 

Smith, Karen E. "Hypertext-Linking to the 
Future." ONLINE Magazine, Vol. 12, No. 2 (March 
1988): 32-40. 



Hypermedia Bibliography NISI Version 



-261- 



January 1990 



Smith, Karen E. and Stanley B. Zdonik. 
"Intermedia: A Case Study of the Differences 
Between Relational and Object-Oriented Database 
Systems." Proceedings of the Conference on Object- 
Oriented Programming Systems, Languages, and 
Applications (OOPSLA '87). October 4-8, Orlando, 
FL. 16 , 1987. 

Smith, Linda C. "'Memex' as an Image Potentiality 
in Information Retrieval Research and 
Development." in Information Retrieval Research, 
R. N. Oddy, (editor). London: Butterworths, 1981. 
345-369. 

Smolensky, Paul, Brigham Bell, Barbara Fox, 
Roger King and Clayton Lewis. "Constraint-based 
Hypertext for Argumentation." Hypertext '87 
Papers. November 13-15, 1987, Chapel Hill, NC. 
New York: ACM, 1989. 215-246. 

Storrs, Graham. "The Alvey DHSS Large 
Demonstrator Project Knowledge Analysis Tool: 
KANT." in Hypertext: Theory into Practice, Ray 
McAleese, (editor). Norwood, NJ: Ablex Publishing 
Corporation, 1989. 148-156. 

Stotts, P. David and Richard Furuta. "Adding 
Browsing Semantics to the Hypertext Model." 
Proceedings of the ACM Conference on Document 
Processing Systems. December 5-9, 1988, Santa Fe, 
NM. New York: ACM, 1988. 43-50. 

Stotts, P. David and Richard Furuta. "Petri Net 
Based Hypertext: Document Structure with 
Browsing Semantics." ACM Transactions on 
Information Systems,, Vol. 7, No. 1 (January 1989): 
3-29. 

Streitz, Norbert A., Jorg Hanneman and Manfred 
Thuring. "From Ideas and Arguments to 
Hyperdocuments: Travelling Through Activity 
Spaces." Hypertext '89 Proceedings. November 5-7, 
1989, Pittsburgh, PA. New York: ACM, 1989. 343- 
364. 

Svibely, J. R. and J. W. Smith. "A Prototypic 
Hypertext Information System for Pathologist." 
Informatics in Pathology, Vol. 1 (1986): 133-142. 

Tanguay, David A. A General System for Managing 
Videotex Information Structures, CS-86-23. 
University of Waterloo, Department of Computer 
Science Technology, June 1986. 

Tchudi, S. "Invisible Thinking and the Hypertext." 
English Journal, Vol. 77, No. 1 (1988): 22-30. 



Thompson, Bev and Bill Thompson. "Hyping Text: 
Hypertext and Knowledge Representation." AI 
Expert, (August, 1987): 25-28. 

Thorsen, Linda J. and Mark Bernstein. "Developing 
Dynamic Documents: Special Challenges for 
Technical Communicators." Proceedings of the 34th 
International Technical Communications 
Conference. Denver, CO, 1987. 

Thursh, Donald, Frank Mabry and Allan H. Levy. 
"Computers and Videodiscs in Pathology 
Education: ECLIPS as an Example of One 
Approach." Human Pathlology, Vol. 17 (1986): 216- 
218. 

Thursh, Donald and Frank Mabry. "A Knowledge- 
Based Hypertext of Pathology." Proceedings of the 
Fourth Annual Symposium on Computer 
Applications in Medical Care, 1980. 

Thursh, Donald and Frank Mabry. "A Knowledge- 
Based System for Pathology Education." Bulletin of 
Pathology Education, Vol. 6, No. 2 (Fall 1980): 36- 
45. 

Thursh, Donald, Frank Mabry and Allan H. Levy. 
"The Knowledge Access, Management, and 
Extension System in Pathology." Proceedings of the 
AAMSI Congress. Allan H. Levy and B. T. 
Williams, (editors), 1985. 

Tompa, Frank Wm. "A Data Model for Flexible 
Hypertext Database Systems." ACM Transactions 
on Information Systems, Vol. 7, No. 1 (January 
1989): 85-100. 

Tompa, Frank Wm. "Retrieving Data through 
Telidon." Proceedings CIPS, 1982. 

Tompa, Frank Wm, Jan Gecsei and Gregor V. 
Bochmann. "Alternative Database Facilities for 
Videotex." in The Telidon Book, D. Godfrey and E. 
Chang, (editors). Press Porcepic, 1981. 

Travers, Michael. "A Visual Representation for 
Knowledge Structures." Hypertext '89 Proceedings. 
November 5-7, 1989, Pittsburgh, PA. New York: 
ACM, 1989. 147-158. 

Trigg, Randall H. "A Networked-based Approach 
to Text Handling for the On-line Scientific 
Community." University of Maryland, 1983. 

Trigg, Randall H. "Guided Tours and Tabletops: 
Tools for Communicating in a Hypertext En- 
vironment." ACM Transactions on Office 
Information Systems, Vol. 6, No. 4 (October 1988): 
398-414. 



Hypermedia Bibliography NISI Version 



-262- 



January 1990 



Trigg, Randall H. and Peggy M. Irish. "Hypertext 
Habitats: Experiences of Writers in NoteCards." 
Hypertext '87 Papers. November 13-15, 1987, 
Chapel Hill, NC. New York: ACM, 1989. 89-108. 

Trigg, Randall H., Thomas P. Moran and Frank G. 
Halasz. "Adaptibility and Tailorability in 
NoteCards." Proceedings of INTERACT '87. 
September, Stuttgart, West Germany. 1987. 

Trigg, Randall H. and Lucy A. Suchman. 
"Collaborative Writing in NoteCards." in 
Hypertext: Theory into Practice, Ray McAleese, 
(editor). Norwood, NJ: Ablex Publishing 
Corporation, 1989. 45-61. 

Trigg, Randall H., Lucy A. Suchman and Frank G. 
Halasz. "Supporting Collaboration in NoteCards." 
Computer-Supported Cooperative Work (CSCW 
'86) Proceedings. December 3-5, Austin, TX, 1986. 
153-162. 

Trigg, Randall H. and Mark Weiser. "TEXTNET: A 
Network-Based Approach to Text Handling." ACM 
Transactions on Office Information Systems, Vol 4, 
No. 1 (January, 1986): 1-23. 

Tsai, C. "Hypertext: Technology, Applications, and 
Research Issues." Journal of Educational Technology 
Systems, Vol. 17, No. 1 (1988): 3-14, 

Underwood, J. "Language Learning and 
•Hypermedia"." ADFL Bulletin, Vol, 19, No. 4 
(1988): 13-17. 

Utting, Kenneth and fJicole Yankelovich. "Context 
and Orientation in Hypermedia Netv/orks." ACM 
Transactions on Information Systems, Vol. 7, No. 1 
(January, 1989): 58-84. 

van Dam, Andries. PRESS (File Retrieval and 
Editing System). Barrington, RI: Text Sj'stems, July 
1971. 

van Dam, Andries. "Hypertext '87 Keynote 
Address." Communications of the ACM, Vol. 31, 
No. 7 (July 1988): 887-895. 

van Dam, Andries and David E. Rice. "Computers 
and Publishing: Writing, Editing and Printing." in 
Advances in Computers, New York: Academic Press, 
1970. 

van Dam, Andries and David E. Rice. "On-Liae 
Text Editing: A Survey/' Computing Surveys, Vol 
3, No. 3 (September 1971): 93-114, 



van der Merwe, D. P. "Annotating Literary Texts 
with Hypertext." Proceedings of the 12th In- 
ternational Online Information Meeting. December 
6-8, 1988, London, England. Oxford and New Jersey: 
Learried Information, 1988. 239-247. 

VanLehn, Kurt. Theory Reform Caused by an 
Argumentation Tool, ISL-11. Xerox Palo Alto 
Research Center, July, 1985. 

V\^<k\ker, Donald. Knowledge R.esource Tools for 
Accessing Large Text Files, 85-21233-25. Bell 
Communications Research, 1985. 

Walker, Janet H. "The Document Editor: A Support 
Environment for Preparing Technical Documents." 
Proceedings of the ACM SIGPLAN jSIGOA 
Conference on Text Manipulation. Portland, OR: , 
June 1981. 44-50. 

Walker, Janet H. "Symbolics Sage: A Doc- 
umentation Support System." Intellectual Lever- 
age: The Driving Technologies, IEEE Spring 
Compcon84, 1984. 478-183. 

Walker, Janet H. "Document Examiner: Delivery 
Interface for Hypertext Documents." Hypertext '87 
Papers. November 13-15, 1987, Chapel Hill, NC. 
Nev/ York: ACM, 1989. 307-324. 

Walker, Janet H. "The Role of Modularity in 
Document Authoring Systems." Proceedings of the 
ACM Conference on Document Processing Systems. 
December 5-9, 1988, Santa Fe, New Mexico. New 
York: ACM,, 1988. 117-124. 

Walker, Janet H. "Supporting Document De- 
velopment in Concordia." IEEE Computer, (January, 
1988): 48-59. 

Walker, Janet H. "Authoring Tools for Complex 
Document Sets." in The Society of Text: Hypertext, 
Hypermedia, and the Social Construction of 
Information, Edward Barrett, (editor). Cambridge, 
MA: The MIT Press, 1989. 132-147. 

Walker, Janet H. and R. L. Bryan. "An Editor for 
Structured Technical Documents." Protext IV. 

Walter, Mark. "IRIS's Intermedia: Multiuser Hy- 
pertext." Seybold Report on Publishing Systems, 
Vol. 18, No. 21 (August 7, 1989): 20-32. 

Weyer, Stephen A. "As We May Learn." in 
Interactive Multimedia, Sueann Ambron and 
Kristina Hooper, (editors). Redmond, WA: 
Microsoft Press, 1988. 87-104. 



Hypermedia Bibliography N!ST Version 



-263- 



January 1990 



Weyer, Stephen A. "The Design of a DynaiTiic Book 
for Information Search." International Journal of 
Man-Machine Studies, Vol. 17, No. 1 (July 1982): 
87-107. 

Weyer, Stephen A. Searching for Information in a 
Dynamic Book, Report SCG-1 (Also published as a 
Stanford University dissertation). Xerox Palo Aito 
Research Center, Palo Alto, CA, February 1982. 

Weyer, Stephen A. and Alan H. Borning. "A 
Prototype Electronic Encyclopedia." ACM Trans- 
actions on Office Information Systems, Vol. 3, No. 1 
(January 1985): 63-88. 

White, J. E. "A High-Level Framework for 
Network-based Resource Sharing." AFIPS Pro- 
ceedings, National Computer Conference. June 7-10, 
1976, New York. Montvale, New Jersey: AFIPS 
Press, 1976. 561-570. 

Wilder, H. A. and Nick F. Maxemchuck. "Virtual 
Editing: II. The User Interface." Proceedings of 
SIGOA Conference Office Automation Systems. June 
21-23, Philadelphia, PA. New York: ACM, 1982. 
41-46. 

Wilson, Kathleen S. Palenque: An Interactive 
Multimedia Optical Disk Prototype for Children. 
Working Paper No. 2, Bank Street College of 
Education, Center for Children and Technology, 
New York, 1987. 

Wilson, Kathleen S. "Palenque: An Interactive 
Multimedia Digital Interactive Prototype for 
Children." Proceedings of the 1988 ACM Conference 
on Human Factors in Computer Systems (CHI '88), 
May 15-19, Washington, D.C. New York: ACM, 
1988. 275-279. 

Woods, William A. "What's in a Link: Foundations 
for Semantic Networks." in Readings in Knowledge 
Representation, Ronald J. Brachman and Hector J. 
Levesque, (editors). Los Altos, CA: Morgan 
Kaufmann, 1975. 

Yankelovich, Nicole. "The Sampler Companion: 
Four Educational Software Samples." Proceedings 
of Frontiers in Education Fifth Annual Conference. 
October 19-22, Golden, CO, 1985. 

Yankelovich, Nicole, L. Nancy Garrett, Karen E. 
Smith and Norman Meyrowitz. "Issues in Designing 
a Hypermedia Document System: The Intermedia 
Case Study." in Interactive Multimedia, Sueann 
Ambron and Kristina Hooper, (editors). Redmond, 
WA: Microsoft Press, 1988. 33-86. 



Yankelovich, Nicole, Bernard Haan and Steven 
Drucker. "Connections in Context: The Intermedia 
System." Proceedings of the Twenty-First Annual 
Hawaii International Conference on System 
Sciences. Bruce D. Shriver, (editor). January 5-8, 
1988, Kailua-Kona, HA. Washington, D.C: Com- 
puter Society Press of the IEEE. 715-724. 

Yankelovich, Nicole, Bernard J. Haan, Norman 
Meyrowitz and Steven M. Drucker. "Intermedia: 
The Concept and the Construction of a Seamless 
Information Environment." IEEE Computer, Vol. 21, 
No. 1 (January 1988): 81-96. 

Yankelovich, Nicole, George Landow and Peter 
Heywood. Designing Hypermedia "Ideahases" — 
The Intermedia Experience, Technical Report 87-4. 
IRIS, Brown University, Providence, RI, 1987. 

Yankelovich, Nicole, Norman Meyrowitz and 
Andries van Dam. "Reading and Writing the 
Electronic Book." IEEE Computer, Vol. 18, No. 10 
(October 1985): 16-30. 

Yankelovich, Nicole and Andries van Dam. 
"Spinning Scholarly Webs." The Annenberg/CPB 
Project Report to Higher Education, The An- 
nenberg/ CPB Project, Washington, D.C, 1987. 

Yoder, Elise A., Robert M. Akscyn and Donald L. 
McCracken. "Collaboration in KMS, A Shared 
Hypermedia System." Proceedings of the 1989 ACM 
Conference on Human Factors in Computer Systems 
(CHI '89), April 30-May 4, 1989, Austin, TX. New 
York: ACM, 1989. 37-42. 

Yoder, Elise and Thomas C. Wettach, Esq. "Using 
Hypertext in a Law Firm." Hypertext '89 Pro- 
ceedings. November 5-7, 1989, Pittsburgh, PA. New 
York: ACM, 1989. 159-168. 

Young, Jeffrey S. "Hypermedia." MacWorld, Vol. 3, 
No. 3 (March 1986): 116-121. 

Zellweger, Polle T. "Active Paths Through 
Multimedia Documents." Proceedings of the EP '88 
Conference on Electronic Publishing, Document 
Manipulation and Typography. April 20-22, 1988, 
Nice, France. 

Zellweger, Polle T. "Scripted Documents: A Hy- 
permedia Path Mechanism." Hypertext '89 Pro- 
ceedings. November 5-7, 1989, Pittsburgh, PA. New 
York: ACM, 1989. M4. 



Hypermedia Bibliography NISI Version 



-264- 



January 1990 



Participants List 
Hypertext Standardization Workshop 



Carol A. Adams 
IBM 

1 1400 Bumet Rd. 
Austin, TX 78758 

Peter Aiken 

George Mason University 
MS ST-203 

Fairfax, VA 22030-4444 
paikenCg) gmuv ax2.gmu.edu 

Robert Akscyn 
Knowledge Systems Inc. 
4750 Old WilUam Penn Hwy. 
MurrysviUe, PA 15668 

Frank Armour 

George Mason University 

MS ST-203 

Fairfax, VA 22030-4444 
JeanBaronas 

National Institute of Standards & Technology 
Room B263, Bldg. 225 
Gaithersburg, MD 20899 
baronas(2) asl.ncsl.nist.gov 

Denise A. D. Bedgord 
Consultant 
12307 Lima Drive 
Silver Spring, MD 20904 

Daniel R. Benigni 

National Institute of Standards & Technology 
Room A266, Bldg. 225 
Gaithersburg, MD 20899 
benigm@ise.ncsl.nist.gov 



Tim Bcrncrs-Lcc 
CERN 

1211 Geneva 23 

SWITZERLAND 

tim@online.cem.ch 

James D. Black 

House of Representatives 

MS-H2635 

US House of Representatives 
Washington, DC 20515 
fjb(2)mios.house.gov 

A. R. Briggs 
Xerox Corporation 
2000 Corp. Ridge 
McLean, VA 22102 

Diane Brown 
Mitre Corporation 
7525 Colshire Drive 
Mailcode Z580 
McLean, VA 22102 

Karin Bruce 

James Martin Associates 
1850 Centennial Pk Drive 
Suite 200 
Reston, VA 22091 

John C. Chen 
Texas Instruments 
P.O. Box 655474 
MS 238 

DaUas.TX 75265 
jcen(a)csc.ti.com 



-265- 



Qi Fan Chen 

Virginia Tech 

Dept. of Computer Science 

552 McBryde Hall 

Blacksburg, VA 24061 

chenq%fox(a)vtopus. cs.vt.edu 

Paul Clapis 

Hughes Danbury Optical Sy 
25 Science Pk 
New Haven, CT 06511 
cl api s(S) celrax . y ale .c s . edu 

Fred Cole 

Computing Laboratory 
University of Kent 
Canterbury 
KentCT2 7NF 
ENGLAND 
fcc@ukc.ac.wk 

Joe Collica 

National Institute of Standards & Technology 
Room A266, Bldg. 225 
Gaithersburg, MD 20899 
collica(2)ise.ncsl.nist.gov 

Gregory Crane 
Harvard University 
Perseus Project 
Dept. of Classics 
319Boylston Hall 
Cambridge, MA 02138 
cr anecg) wj hl2 .harv ard. edu 

Andrew Dove 
Landmark Graphics 
333 Cypress Run 
Houston, TX 77094 
andrew@lgc.com 

Edward Edmiston 
Mitre Corporation 
7525 Colshire Drive 
Mailcode Z580 
McLean, VA 22102 



Lawrence E. Fitzpatrick 
Personal Library Software 
15215 Shady Grove Rd 
Suite 204 

RockviUe, MD 20850 

Valerie Florance 
Welch Med Library, JHU 
1830 Monument Street 
3rd Floor 

Baltimore, MD 21205 
vf@welchlab.jhu.edu 

Dr. Edward A. Fox 

Dept. of Computer Science 

562 McBr>'de Hall 

VPI&SU (Virginia Tech) 

Blacksburg, VA 24016-0106 

fox@vtopus.cs.vt.edu 

David Fristrom 

Interleaf 

10 Canal Park 

Cambridge, MA 02141 

Richard Furuta 

Dept. of Computer Science 

University of Maryland 

College Park, MD 20742 

furuta@cs.umd.edu 

Leonard Gallagher 

National Institute of Standards & Technolog 
Room A266, Bldg. 225 
Gaithersburg, MD 20899 
gallagher@ise.ncsl.nist.gov 

Kevin Gamble 
USDA 

3322 Smith Bldg. 
Washington, DC 202500-0900 
kgamble@cas.orst.edu 



-266- 



Bob Glushko 
Search Technology, Inc 
4725 Peachtree Comers Circle 
Suite 200 

Norcross.GA 30092 
srchtec!glushko@gatech.edu 

Louis Gomez 

Bellcore 

445 South Street 

Morristown, NJ 07961 

gomez@ bellcore . com 

Frank Halasz 

Systems Sciences Laboratory 
Xerox Palo Alto Research Center 
3333 Coyote Hill Road 
Palo Alto, CA 94304 
halasz@xerox.com 

Seymour Hanfling 

US Army Research Institute 

5001 Eisenhower Avenue 

PREI-IC 

Alexandria, VA 22333 

Dr. Shoshana Hardt-Komacki 

Bellcore 

2A-273 

445 South Street 
Morristown, NJ 07961 
shoshi@bellcore.com 

Michael Hogan 

National Institute of Standards & Technology 
Room B168, Bldg. 225 
Gaithersburg, MD 20899 

Kris Houlahan 
DEC 

8300 Professional PI 
Suite 119 

Landover,MD 20785 



Danny B. Lange 

Bruel & Kjacr Industri A/S 

Department of Development 

DK-2850 Nacrum 

DENMARK 

danny.lange@bk.dk 

John J. Leggett 
Hypertext Research Lab 
Dept. of Computer Science 
Texas A&M University 
CoUege Station, TX 77843-31 12 
leggett@cssun.tamu.edu 

William P. Loftus 
Unisys Corporation 
Rt. 252 & Central 
1300 Wing 
PaOli,PA 19301 
wpl@prc.unisys.com 

Kathryn C. Malcolm 
Boeing Computer Corporation 
P.O. Box 24346 
Seattle, WA 98124-0346 

Catherine Marshall 
Systems Sciences Laboratory 
Xerox Palo Alto Research Center 
3333 Coyote Hill Road 
Palo Alto, CA 94304 
marshall@xerox.com 

Robert. Smith Midford 
Federal Computer Week 
4141 N. Anderson 
413 

Arlington, VA 22203 

Robert Miglin 
ANSER Analytic Services 
Crystal Gateway 3, Suite 800 
1215 Jefferson Davis Hwy. 
Arlington, VA 22202 



-267- 



Judi Moline 

National Institute of Standards & Technology 
Room B266, Bldg. 225 
Gaithersburg, MD 20899 
molineCg) asl.ncsl.nist.gov 

Howard Moncarz 
NIST 

Metrology, Rm A 127 
Gaithersburg, MD 20899 
moncarz(a)cme.nist.gov 

Fontaine Moore 
CACI, Inc.-Federal 
8260 Willow Oaks Drive 
Fairfax, VA 22031 

Prof. Steven R. Newcomb 
Center for Music Research 
Florida State University 
Tallahassee, FL 32306-2098 
cmr!sm(a)bikini.cis.ufl.edu 

Charles K. Nicholas 
Computer Sciences Dept. 
U.M.B.C. 

5401 Wilkens Avenue 
Catonsville, MD 21228 

Dan Olson 

Boeing Computer Services 
P.O. Box 24346 #6498 
Seattle, WA 98124 

Tim Oren 

Apple Computer Advanced Technology Group 
Apple Computer, Inc. 
20525 Mariani Ave. 
MS 76-2C 

Cupertino, CA 95014 
oren(S) apple.com 



Taeha Park 

KAIST 

P.O.Box 150 

Chongryang-Dongdaeno 

Seoul 

KOREA 

taeha@sorak.kaist.ac.kr 

H. Van Dyke Parunak 

Industry Technology Institute 

P.O. Box 1485 

Ann Arbor, MI 48106 

van@iti.org 

Kenneth Pugh 

Information Navigation, Inc. 
4201 University Drive, Suite 102 
Durham, NC 27707 

John J. Puttress 
AT&T Bell Laboratories 
600 Mountain Ave. 
2C-577 

Murray Hill, NJ 07974 
jp(a)bashful.att.com 

Victor Riley 
IRIS/Brown University 
155 George Street 
Box 1946 

Providence, RI 02906 
var(5)iris.brown.edu 

Louis G. Roberts 
Boeing Computer Services 
P.O. Box 24346 
SeatUe,WA 98124-0346 
lroberts@atc.boeing.com 

Linda Rosenberg 
Goucher College 
Towson,MD 20214 
linda@cs.umbc.edu 



-268- 



Sean Sebastian 
GE Info Systems 
401 N. Washington St. 
MC OTCY 

Rockville, MD 20850 
Andrea Spinelli 

Bull HN Information Systems Italia S.p.A 
Via Vittor Pisani, 10 
20100 Miiano 
ITALY 

Duane Stone 

McDonnell Douglas 

P.O. Box 516 

MS 100 2125 

St. Louis, MO 63166 

stone@team-l .mdc.com 

David Stotts 
University of Maryland 
Dept. of Computer Science 
CoUege Park, MD 20742 
pds@cs.umd.edu 

Craig W. Thompson 
Info. Tech. Laboratory 
Texas Instruments Inc. 
P.O. Box 655474, MS 238 
Dallas, TX 75265 
thompson(a)csc.t.i.com 

CHfford Urr 

Planning Analysis Corporation 
Suite 890 

1010 North Glebe Road 
Arlington, VA 22201 

Janet H. Walker, Ph.D 
Digital Equipment Corp. 
One Kendall Square 
Bldg. 700 

Cambridge, MA 02139 
jwalker(a) crl.dec.com 



David Wojick 
CACI, Inc.-Federal 
8260 Willow Oaks Drive 
11/8 

Fairfax, VA 22031 

Magdalena Wright 
GMA Industries 
P.O.Box 16248 
Arlington, VA 22215 

Donald Young 
McDonnell Douglas 
Dept. H093/HQ 
MS 100 2125 
P.O. Box 516 
St. Loius,MO 63166 



-269- 



NBS-n4A iREv. 2-ec) 



U.S. DEPT. OF COMM. 


1. PUBLICATION OR 


2. Performing Organ. Report No, 


3. Publica 


.ion Date 


BIBLIOGRAPHIC DATA 


REPORT NO. 






SHEET (See instructions) 


NIST/SP-500/178 




March 


1990 



4. TITLE AND SUBTITLE 



Proceedings of the Hypertext Standardization Workshop 

January 15-18, 1990, National Institute of Standards and Technology 



5. AUTHOR(S) 

Judi Moline, Dan Benigni, Jean Baronas 


6. PERFORMING ORGANIZATION (If joint or other titan NBS, ,=:ee instructions) 

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY 
(lormerly NATIONAL BUREAU OF STANDARDS) 
U.S. DEPARTMENT OF COMMERCE 
GAITHERSBURQ, MD 20899 


7. Contract/Grant No. 


8. Type of Report & Period Covered 

Final 



9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State, ZIP) 



Same as item #6 



10. SUPPLEMENTARY NOTES 



|~ I Document describes a computer program; Sh-iSS, FIPS Software Summary, is attached. 



11. ABSTRACT (A 200-word or /ess factual summary of most si gnificant information . If document includes a si gnificant 
bi bliography or literature survey, mention it here) 

This report constitutes tlie proceedings of a three day workshop on Hypenext 
Standardization held at the National Institute ov Standards and Technology (NIST) on 
January 16 - 18, 1990. Effons towards standardization of hypertext have already been 
initiated in various interested organizations. In recognition of these existing effons, NIST 
sponsored the Hypertext Standardization Workshop organized by the Hj'pertext 
Competence Project of the National Computer Systems Laboratory. 

The major purpose of the Hypertext Standardization Workshop was to provide a 
forum for presentation and discussion of existing and proposed approaches to hs'pertext 
standardization. The stated workshop goals were to consider hypertext system definitions, 
to identify viable approaches for pursuing standards, to seek commonality among 
alternatives whenever possible, and to make progress towards a coordinated plan for 
standards development, i.e. a hypertext reference model. The workshop announcement 
solicitated contributed papers on any aspect of hypertext standardization, including 
assertions that standardization is premature or inadvisable. Approximately 30 
connibutions were received and distributed to the 65 workshop participants on the first 
day. 

The workshop included plenary sessions and three discussion groups. This 
proceedings includes the papers selected for presentation in pleniirj' sessions, reports of 
the discussion groups, and supplementary' materials. Major conclusions of the workshop 
were that the discussion groups should continue their technical efforts, and that NIST 
should sponsor at least one more workshop to provide a forum for public discussion of 
progress. 



12. KEY WORDS (S/x to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolons, 

Hypermedia; hypertext; standards 



13. AVAILABILITY 



[X] Unl imited 

[ j For Official Distribution. Do Not Release to NTIS 

[X] Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 



20402. 



[jp Order From National Technical Information Service (NTIS). Springfield, VA. 22151 



14. NO. OF 

PRINTED PAGES 



259 



15. Price 



•il^- U.S. GOVERNMENT PRI^m^^GO(-F!CE: 1S90 — 2 El -913 '20574 



USCCMM-DC 6C43-P80 



ANNOUNCEMENT OF NEW PUBLICATIONS ON 
COMPUTER SYSTEMS TECHNOLOGY 



Superintendent of Documents 
Government Printing Office 
Washington, DC 20402 



Dear Sir: 

Please add my name to the announcement list of new publications to be issued in 
the series: National Institute of Standards and Technology Special Publication 500-. 

Name 

Company 

Address 

City State Zip Code 

(Notification key N-503) 



NIST 



Technical Publications 

Periodical 

Journal of Research of the National Institute of Standards and Technology — Reports NIST research 
and development in those disciplines of the physical and engineering sciences in which the Institute 
is active. These include physics, chemistry, engineering, mathematics, and computer sciences. 
Papers cover a broad range of subjects, with major emphasis on measurement methodology and 
the basic technology underlying standardization. Also included from time to time are survey articles 
on topics closely related to the Institute's technical and scientific programs. Issued six times a year. 

Nonperiodicals 

Monographs — Major contributions to the technical literature on various subjects related to the 
Institute's scientific and technical activities. 

Handbooks — Recommended codes of engineering and industrial practice (including safety codes) de- 
veloped in cooperation with interested industries, professional organizations, and regulatory bodies. 
Special Publications — Include proceedings of conferences sponsored by NIST, NIST annual reports, 
and other special publications appropriate to this grouping such as wall charts, pocket cards, and 
bibliographies. 

Applied Mathematics Series — Mathematical tables, manuals, and studies of special interest to physi- 
cists, engineers, chemists, biologists, mathematicians, computer programmers, and others engaged in 
scientific and technical work. 

National Standard Reference Data Series — Provides quantitative data on the physical and chemical 
properties of materials, compiled from the world's literature and critically evaluated. Developed un- 
der a worldwide program coordinated by NIST under the authority of the National Standard Data 
Act (Public Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data (JPCRD) 
is published quarterly for NIST by the American Chemical Society (ACS) and the American Insti- 
tute of Physics (AIP). Subscriptions, reprints, and supplements are available from ACS, 1155 Six- 
teenth St., NW., Washington, DC 20056. 

Building Science Series — Disseminates technical information developed at the Institute on building 
materials, components, systems, and whole structures. The series presents research results, test 
methods, and performance criteria related to the structural and environmental functions and the 
durability and safety characteristics of building elements and systems. 

Technical Notes — Studies or reports which are complete in themselves but restrictive in their treat- 
ment of a subject. Analogous to monographs but not so comprehensive in scope or definitive in 
treatment of the subject area. Often serve as a vehicle for final reports of work performed at NIST 
under the sponsorship of other government agencies. 

Voluntary Product Standards — Developed under procedures published by the Department of Com- 
merce in Part 10, Title 15, of the Code of Federal Regulations. The standards establish nationally 
recognized requirements for products, and provide all concerned interests with a basis for common 
understanding of the characteristics of the products. NIST administers this program as a supplement 
to the activities of the private sector standardizing organizations. 

Consumer Information Series — Practical information, based on NIST research and experience, cov- 
ering areas of interest to the consumer. Easily understandable language and illustrations provide use- 
ful background knowledge for shopping in today's technological marketplace. 
Order the above NIST publications from: Superintendent of Documents, Government Printing Office, 
Washington, DC 20402. 

Order the following NIST publications — FIPS and NISTIRs—from the National Technical Information 
Service, Springfield, VA 22161. 

Federal Information Processing Standards Publications (FIPS PUB)— Publications in this series col- 
lectively constitute the Federal Information Processing Standards Register. The Register serves as 
the official source of information in the Federal Government regarding standards issued by NIST 
pursuant to the Federal Property and Administrative Services Act of 1949 as amended, Public Law 
89-306 (79 Stat. 1127), and as implemented by Executive Order 11717 (38 FR 12315, dated May 11, 
1973) and Part 6 of Title 15 CFR (Code of Federal Regulations). 

NIST Interagency Reports (NISTIR) — A special series of interim or final reports on work performed 
by NIST for outside sponsors (both government and non-government). In general, initial distribu- 
tion is handled by the sponsor; public distribution is by the National Technical Information Service, 
Springfield, VA 22161, in paper copy or microfiche form. 



U.S. Department of Commerce 

National Institute of Standards and Technology 
(formerly National Bureau of Standards) 
Gaithersburg, MD 20899 

Official Business 

Penalty for Private Use $300